Even if given GstVideoChromaSite and/or GstVideoColorimetry has unknown
value(s), assumption for an unknown value should be done by subclass or
downstream element, not a role of video decoder. And subclass might
want to output unknown value as is.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/910>
When user is passing the actual interlace-mode when calling
gst_video_decoder_set_interlaced_output_state() it should not be
overidden by the input interlace-mode.
Needed to fix#825 as we want to keep interlace-mode=interleaved from
parsers and have the OMX decoder producing interlace-mode=alternate.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/852>
This allows subclasses that notice missing reference frames to request a
new sync point to allow seamless decoding again. While doing so the
subclass can also signal whether it wants a) all following input frames
until the sync point to be discarded or b) all output frames until the
sync point to be marked as corrupt.
Sending of force-keyunit events for this can be throttled by the
application via the "min-force-keyunit-interval" property.
This replaces custom behaviour for the same in various decoders, for
example openh264dec.
Based on patches by Haakon Sporsheim <haakon@pexip.com> and
Stian Selnes <stian@pexip.com>.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/730>
If the first frame(s) at the very beginning or after a flush are not a
sync point then the base class would discard them before passing them to
the subclass.
This also fixes the previously broken distance_from_sync handling: it
was never reset at sync points.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/730>
This can be used by applications to configure decoders so that corrupted
frames are directly discarded instead of being forwarded inside the
pipeline. It is a replacement for the "output-corrupt" property of the
ffmpeg decoders.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/730>
This can be used by subclasses to mark output frames as known to be
corrupted, for example if reference frames were missing. ffmpeg's
decoders can signal this.
In addition this flag is propagated downstream if the input frame had it
set.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/730>
For audio we copy metas that have no tags at all, or that only have the
"audio" and/or "audio-channels" tag. Audio codecs don't change the
audio aspect of the stream and in almost all cases don't change the
number of channels. They might however change the sample rate (e.g.
Opus). Subclasses that change the number of channels will have to
override ::transform_meta() accordingly.
For video we copy metas that have no tags at all, or that only have the
"video" and/or "video-size" and/or "video-orientation" tag. Video codecs
don't change the "video" aspect of the stream and in almost all cases
don't change the resolution or orientation. Subclasses that rescale or
change the orientation will have to override ::transform_meta()
accordingly.
See https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/576#note_610581
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/801>
Also not optimal but at least simplifies the code a bit and doesn't
require g_list_length() and g_list_append() in a few places.
For 2.0 there are some more candidates to change but unfortunately
they're currently part of the API.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/683>
When receiving an instant-rate-change event, store the updated
seek flags and replace the flags in any input segments with them
to allow for instant switching between trickmodes and not.
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.
