At the moment, we only posted QoS messages when frame_drop() was
called, but not in finish_frame() when QoS triggered a late push.
This should fix applications that tries to account the dropped
frames. We also emit a warning on drops so it's more clear what is
happening.
gst_video_decoder_negotiate_default_caps() is meant to pick a default output
format when we need one earlier because of an incoming GAP.
It tries to use the input caps as a base if available and fallback to a default
format (I420 1280x720@30) for the missing fields.
But the framerate and pixel-aspect were not explicitly passed to
gst_video_decoder_set_output_state() which is solely relying on the input format
as reference to get the framerate anx pixel-aspect-ratio.
So there is no need to manually handling those two fields as
gst_video_decoder_set_output_state() will already use the ones from
upstream if available, and they will be ignored anyway if there are not.
This also prevent confusing debugging output where we claim to use a
specific framerate while actually none was set.
The gst_video_decoder_clip_and_push_buf() now drops the internal stream
lock while pushing. This means, the output_queued list could be modififed
during that time. To make the code safe again, we delete the link before
pushing the data. The walk pointer will later be updated with the list
head, which makes it safe in case the list was modififed.
https://bugzilla.gnome.org/show_bug.cgi?id=715192
Release STREAM_LOCK before calling gst_pad_push() and take it
back afterward so that upstream isn't blocked while output
buffer is being pushed downstream.
https://bugzilla.gnome.org/show_bug.cgi?id=715192
Add a variant of gst_video_decoder_set_output_state() that allows the user
to pass an interlacing mode as well. This is needed to ensure that
gst_video_info_set_interlaced_format() is used instead so that
GstVideoInfo.size is correctly initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=796106
V4L2 and OMX decoder don't support draining and keeping reference
frames. As a side effect, these decoder just stops working on
gaps/discont. When this drain was introduced, the commit stated that
this was for TRICKMODE_KEY_UNITS, so only drain if running in this mode.
https://bugzilla.gnome.org/show_bug.cgi?id=796771
When the input is TRICKMODE_KEY_UNITS, we expect to only receive keyframes
which we want to decode/push immediately. Therefore don't queue them.
If upstream didn't send just keyframes (which is the ideal situation), two
different things can happen:
1) Either the subclass checks the segment flags and properly configures
the decoder implementation to only decode/output keyframes,
2) Or the subclass really decodes and outputs everything, in which case
the reverse frames will end up arriving "late" downstream (and will
be dropped). If upstream did properly send GOP in reverse order, we
still end up just showing keyframes (but at the overhead of decoding
everything).
https://bugzilla.gnome.org/show_bug.cgi?id=777094
Always put multiview-caps onto the output caps, assuming
mono if we've got no other information. It's still easy for
downstream elements to override using a capssetter or event
probe if desired.
https://bugzilla.gnome.org/show_bug.cgi?id=776172
Track how long it takes to generate the first buffer after a flush
as a simple measure of how efficient the decoder is at skipping /
rushing to get to the first decode.
Use G_GUINT64_FORMAT for guint64 values.
Introduced by fcb63e77a9
Found by Alexander Larsson
gstvideodecoder.c: In function 'gst_video_decoder_have_frame':
gstvideodecoder.c:3312:51: error: format '%u' expects argument of type 'unsigned int', but argument 8 has type 'guint64 {aka long long unsigned int}' [-Werror=format=]
Don't guess a timestamp of the start of the segment when running
in reverse mode, as more likely it means we're discontinuous somewhere
in the middle of the segment, and we'll fix up timestamps once
the frames are decoded and reversed.
When a PTS is not set, we still want to store the rest of the
buffer information, or else we lose important things like the
duration or buffer flags when parsing.
Refuse to answer BYTES queries ourselves. The only
time they make sense is on raw elementary streams,
in which case upstream would already have answered.
https://bugzilla.gnome.org/show_bug.cgi?id=757631
It adds a third argument to pass GstBufferPoolAcquireParams
to gst_buffer_pool_acquire_buffer.
If a user subclasses GstBufferPoolAcquireParams, this allows to
pass an updated param to the underlying buffer pool at each
gst_video_decoder_allocate_output_frame_with_params call.
https://bugzilla.gnome.org/show_bug.cgi?id=773165
Also the format must be fixed on the default raw caps. If not
gst_video_info_from_caps() will fail and
gst_video_decoder_negotiate_default_caps() return FALSE.
The test simulates the use case where a gap event is received before
the first buffer causing the decoder to fall back to the default caps.
https://bugzilla.gnome.org/show_bug.cgi?id=773103
We need to take into account the input segment flags to know whether
we should drain the decoder after a new keyframe in trick mode.
Otherwise we would have to wait for the next frame to be outputted (and
the segment to be activated) which ... well ... kind of beats the whole
point of this draining :)
And especially don't use the stream lock for that, as otherwise non-serialized
queries (CONVERT) will cause the stream lock to be taken and easily causes the
application to deadlock.
https://bugzilla.gnome.org/show_bug.cgi?id=768361
For reverse playback it is important to handle correctly the frame sync
points, which is set when the input buffer doesn't have the DELTA_UNIT flag.
This is handled correctly when decoder is packetized, but when it is not the
frame's sync point is not copied, and the reverse playback never decodes frame
batches.
The current patch adds the buffer's flags to the Timestamp list, where the
timestamp and duration of the input buffers are hold.
There were two consecutive log messages in gst_video_decoder_decode_frame().
Given the information they provide, it is more efficient to squash them into a
single one.
The playback rate is hold in the input_segment member variable, not in the
output_segment, and the parse_gather list was never filled because of that.
This patch changes the comparison with input_segment.
The output segment is only set up after data is output, which might be far in
the future for reverse playback. Also we are here interested in the state at
the current *input* frame (which is the keyframe), not any possible output.
For reverse playback the same behaviour was already implemented in
flush_parse().
For reverse playback, chain_forward() is only used to gather frames and not
for decoding, and it is actually called by the draining logic, causing an
infinite recursion.
While it's a bit tricky to discard frames *before* decoding (because
we might not be sure which data is needed or not by the decoder), we
can discard them after decoding if they are too late anyway.
Any following basetransform based element or similar would drop the frame too.
When asked to just decode keyframe, if we got a keyframe drain out
the decoder straight away.
This avoids having to wait for the next frame and reduces delay even
more.
https://bugzilla.gnome.org/show_bug.cgi?id=767232
