If the driver requires more data, just unref the frame at the moment
then retreive/finish the frame after encoding is finished.
This also fixes a memory leak.
https://bugzilla.gnome.org/show_bug.cgi?id=790312
Fixes outputted frame sequence when performing a seek
i.e. when seeking backwards, the first frame after the seek was a frame
from the future. This would result in GstVideoDecoder essentially
marking all the timestamps as essentially bogus and the base class would
attempt to compensate. A visible indication of this was 'decreasing timestamp'
warning after a seek.
https://bugzilla.gnome.org/show_bug.cgi?id=790478
The "fields" flag is ignored because currently GStreamer doesn't support
having only top or only bottom fields inside a frame. The "drop frame"
flag is ignored because some occurrences have been spotted where it
wasn't set while it should have been. In practice, when we have 29.97 or
59.94 FPS, it's always drop-frame.
https://bugzilla.gnome.org/show_bug.cgi?id=790112
When we receive a video or audio buffer, we calculate the next stream
time based on the current stream time + buffer duration. If the next
buffer's stream time is after that, we issue a warning.
This happens because the stream time incoming from Decklink should be
really constant and without gaps. If there is a gap, it means that
something went wrong, e.g. the internal buffer pool is empty (too many
buffers queued up downstream).
https://bugzilla.gnome.org/show_bug.cgi?id=781776
If we drop many frames at once, printing one message per video frame and
one per audio packet would cause a lot of disk IO. Just print a total at
the end.
https://bugzilla.gnome.org/show_bug.cgi?id=788780
Now that we are doing lazy allocation, we may endup calling _stop()
before the allocator was created. As a side effect, we need to nul-check
the pointer before calling it's method (_clear_cache()).
https://bugzilla.gnome.org/show_bug.cgi?id=787593
DRM_RDWR was not defined until libdrm 2.4.68. However,
in configure.ac we only require libdrm >= 2.4.55.
Seems silly to to bump minimum libdrm version for a simple
define. Thus, define DRM_RDWR if it's not defined.
This fixes compilation error introduced in:
commit 922031b0f9
Author: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Date: Tue Sep 12 12:07:13 2017 -0400
kms: Export DMABuf from Dumb buffer when possible
https://bugzilla.gnome.org/show_bug.cgi?id=787593
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
When we guess the strides, we need to also update the GstVideoInfo.size
otherwise the memory size will be set to something smaller then needed.
This was causing crash with the DMABuf exportation, since we would not
mmap() a large enough buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=787593
The buffer itself is 128 bytes into the allocated memory area, to be
able to store the size and other metadata before it. Freeing the buffer
directly will make malloc moderately unhappy.
If bo allocation failed we destroy the buffer and return GST_FLOW_ERROR,
but the @buffer pointer was still pointing to the address of the
destroyed buffer. gst_kms_sink_copy_to_dumb_buffer() was then trying to
unref it when bailing out causing a crash.
Leave @buffer untouched if allocation failed to fix the crash.
Also remove the check on *buffer being not NULL as gst_buffer_new()
will abort if it failed.
https://bugzilla.gnome.org/show_bug.cgi?id=787442
Implement videooverlay interface in kmssink, divided into two cases:
when driver supports scale, then we do refresh in show_frame(); if
not, send a reconfigure event to upstream and re-negotiate, using the
new size.
https://bugzilla.gnome.org/show_bug.cgi?id=784599
We used to to handle the driver pitch only for single plan video format.
Add support for multi planes format by re-using the extrapolate function
from the v4l2 element.
Also use this pitch to calculate the proper offsets.
Prevent DRM drivers to pick a slow path if the pitches/offsets don't
match the ones it reported.
https://bugzilla.gnome.org/show_bug.cgi?id=785029
No semantic change, just renamed the 'tmp' variable to a more meaningful
name and to use the same structure as in gst_kms_allocator_bo_alloc().
Needed as I'm going to move the gst_memory_init() call after the
allocation of the DUMB buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=785029
HRESULT is unsigned long on Windows, but the Decklink headers define
it to 'int' on Linux. Confusingly, the defines that talk about the
possible return values for it use long constants. The easy fix would
be to change the linux/LinuxCOM.h header, but that's copied from the
decklink SDK.
Change the logging to always upcast to unsigned long while printing
HRESULT for consistency across platforms.
gstdecklinkvideosrc.cpp:425:7: warning: format '%x' expects argument of type 'unsigned int', but argument 8 has type 'HRESULT {aka long int}' [-Wformat]
[and so on]
gstdecklinkaudiosink.cpp:155:19: error: conflicting type attributes specified for 'virtual HRESULT GStreamerAudioOutputCallback::QueryInterface(const IID&, void**)'
In file included from /var/lib/jenkins/workspace/cerbero-cross-mingw32/workdir/mingw/w32/bin/../lib/gcc/i686-w64-mingw32/4.7.3/../../../../i686-w64-mingw32/include/objbase.h:153:0,
from /var/lib/jenkins/workspace/cerbero-cross-mingw32/workdir/mingw/w32/bin/../lib/gcc/i686-w64-mingw32/4.7.3/../../../../i686-w64-mingw32/include/ole2.h:16,
from /var/lib/jenkins/workspace/cerbero-cross-mingw32/workdir/mingw/w32/bin/../lib/gcc/i686-w64-mingw32/4.7.3/../../../../i686-w64-mingw32/include/windows.h:94,
from /var/lib/jenkins/workspace/cerbero-cross-mingw32/workdir/mingw/w32/bin/../lib/gcc/i686-w64-mingw32/4.7.3/../../../../i686-w64-mingw32/include/rpc.h:16,
from win/DeckLinkAPI.h:27,
from gstdecklink.h:35,
from gstdecklinkaudiosink.h:27,
from gstdecklinkaudiosink.cpp:25:
/var/lib/jenkins/workspace/cerbero-cross-mingw32/workdir/mingw/w32/bin/../lib/gcc/i686-w64-mingw32/4.7.3/../../../../i686-w64-mingw32/include/unknwn.h:67:25: error: overriding 'virtual HRESULT IUnknown::QueryInterface(const IID&, void**)'
(and many more)
https://ci.gstreamer.net/job/cerbero-cross-mingw32/6407/console
The default memory allocator of the decklink library allocates
a fixed pool of buffers, and the number of buffers is unknown.
This makes it impossible do useful queuing downstream. The new
memory allocator can create an unlimited number of buffers,
giving all queuing features one would expect from a live source.
https://bugzilla.gnome.org/show_bug.cgi?id=782556
In this patch we keep track of the cached kmsmem in a way
that we can clear the cache during the drain process. This
release the framebuffer before waiting for the next vblank,
hence add support for DRM driver (like Intel one) that release
the associated DMABuf reference asynchronously.
https://bugzilla.gnome.org/show_bug.cgi?id=782774
kmssink keeps a reference on the last rendered buffer. If this buffer
refers to an upstream buffer, it should be should be released on DRAIN
and ALLOCATION queries so all upstream buffers can be returned to the
pool if needed. As the buffer may be used for scanout, we copy this
buffer into a dumb buffer prior to let it go.
Based on patch from Guillaume Desmottes <guillaume.desmottes@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=782774
This otherwise breaks DMABuf reclaiming. This is not visible from
userspace, but inside the kernel, the DRM driver will hold a ref to the
DMABuf object. With a V4L2 driver allocating those DMABuf, it then
prevent changing the resolution and re-allocation new buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=782774
Milliseconds was wrong and made use of this timeout quite
confusing. The code uses the value as microsenconds so
any meaningful number was off by orders of magnitude.
Set the pts and dts on the frame that we receive from the msdk.
Also fix the inverted logic in setting sync points, previously we
were marking all frames as sync points except IDRs.
https://bugzilla.gnome.org/show_bug.cgi?id=782801
When extracting an aux buffer from an MJPG carrier, at
*least* put the original timestamp on it, even if we
fail to apply any other timestamp (which we always do
at the moment, because the timestamp calculating code
was never finished). Apply a DTS using the camera
supplied delay value as well, assuming that there's
no re-ordering going on (there isn't in the C920,
which is really the only extant camera doing this
stuff) and a warning if that turns out not to be true.
