Fix a small race where a group can receive stream-start
and post a pending buffering message just as another
thread posts a different buffering message, causing them
to be received by the application out of order. In the
worst case, this leads the application receiving a
stale 99% buffering message and going back to buffering
right after the 100% buffering message.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1901>
The earlier size of 2 MB was set back in 2009, it doesn't
seem unreasonable to raise it to 8 MB these days. The use
case at hand is matroskademux containing both a video stream
with a very low amount of compression but no decoding latency,
and a H265 stream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1538>
There's a potential race condition with this sort of pipelines on
certain systems (depends on the processing load):
GST_DEBUG_DUMP_DOT_DIR=/tmp \
gst-launch-1.0 uridecodebin3 uri=file://stream.mp4 ! glupload ! \
glimagesink --gst-debug=*:4
Right after the pipeline passes from PAUSED to READY, bin_to_dot_file
dumps uridecodebin3 properties, but current uri and suburi might be
already freed, causing a potential use-after-freed.
This patch makes NULL the current item right after all the play items
are freed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1353>
If the pad does not have a current caps, get_pad() returns the query
caps which can be ANY. In such case the caps does not have any structure
resulting in a critical warning when calling gst_caps_get_structure().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1254>
In the encoded streams we might not have all the information about the
raw video stream, but when reencoding they end up being specified, even
if those are default values.
As vp8 decoders always output frames in some YUV color space we can
ensure that when upstream doesn't specify any value in its caps we
use the default one which is what we end up doing when decoding/reencoding
anyway, so this way downstream (matroskamux in that case) doesn't need
to be able to renegotiate (which it doesn't).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1062>
Retrieving the pad template caps from a ghost pad returns ANY which when
merged with any other caps will return ANY. ANY is not very specific
and may cause suboptimal code paths in e.g. decoders that assume the
lowest common denominator when presented with ANY caps.
Fixes negotiating dma-buf with vaapidecodebin between glupload in the
video sink element.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1144>
If the USE_PLAYBIN3=1 env var is set, we want to replace
playbin with playbin3, but separate to that, we always
want to register the 'playbin3' element so that applications
which explicitly use playbin3 work regardless of the env var.
This fixes `USE_PLAYBIN3=1 gst-validate-launcher`, for example.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1102>
Change locking around group deactivation to avoid deadlocks
when shutting down exactly as a buffering message arrives.
The PLAYBIN3_LOCK now protects the active field of the
source group. Everything else is still protected by the
source-group-lock.
Also properly protect group switching operations with
the PLAYBIN3_LOCK everywhere.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1049>
