This leads to spurious negotiation failures because the configured method can
change over time and caps queries (and thus transform_caps) are happening
independently from configuring caps. Instead prefer the transformed caps of the
current method, but always also return the transformed caps for all other
methods. Previously all other methods would've only been used if the current
method returned empty caps. If a different method is needed later when
configuring the caps, it will be and was selected regardless.
Later during caps fixation, prefer the caps of the current method too for the
fixated caps if possible in any way.
This should preserve the desired behaviour of preferring the current method if
possible but to change to a different method if nothing else is possible, while
also returning consistent (and not too narrow) caps every time.
The way how the current method was checked was also racy as the current method
might change at any moment during caps query handling, and apart from
inconsistent results also a NULL pointer dereference was possible here. Use the
GST_OBJECT_LOCK to protect access to the current method like in other places.
This part of the code was introduced in f349cdccf5
and tried to be fixed multiple times over the years without addressing the root
cause of caps queries and caps configuration happening independently from each
other, e.g. in !2687 and !2699.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8431>
Previously there was no validation at all and the defaults were set if the
colorimetry was not set or invalid, but there's not really any connection
between colorimetry and chroma-site.
More validation could make sense in the future.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8258>
Sometimes the seek to the end of file to determine the duration would trigger a
reset of the source pads, that would confuse the decoder downstream and trigger
an error. So the proposed fix is to not reset pads when the segment event being
processed is the consequence of a seek performed to determine the duration.
Fixes#4212
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/937>
After calculating a correct duration the oggdemux in some cases sets the duration to GST_CLOCK_TIME_NONE.
After that any seek will fail due to the oggdemux calculating a target time after the actual duration.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8296>
With this patch, configure time is identical no matter whether doc is
enabled or not.
The configuration files also now contain explicitly-listed sources with
no wildcards.
For the four libraries where hotdoc needs to use clang to generate the
documentation (as opposed to the rest of the libraries where hotdoc uses
the gir), the script will call pkg-config to determine the appropriate
C flags.
This means a side effect of this patch is that pkg-config files are now
generated for the gstadaptivedemux and gstopencv libraries.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8312>
Some pixel aspect ratios found in dash streams have very large numerators and
denominators (while being close to 1:1). These values can cause integer overflow
during multiplication, leading to negotiation failures.
Add fallback path using gdouble when integer multiplication would overflow,
trading some precision for reliability instead of failing outright.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8262>
The check is exactly the same, but more explicit.
Original commit that introduced the check is
20fb58be19:
---
vorbisdec: don't put invalid bitrate values into the taglist
Bitrates are stored as 32-bit signed integers in the vorbis
identification headers, but seem to be read incorrectly,
namely as unsigned 32-bit integers, into the vorbis structure
members which are of type long, which makes our check for
values <= 0 fail with files that put -1 in there for unset
values.
---
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8229>
appsink was queuing the caps event both in its GstBaseSinkClass.set_caps()
and its GstBaseSinkClass.sink_event() implementation, but only signaling
new_event from `sink_event`.
This caused `new_event` callbacks to start lagging by one.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7749>
