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
