There's no guarantee it will *actually* be the URI which refered to what we are
downloading. It could be a stream URI or anything else.
Instead of putting something wrong, put no (specific) referer as a better choice
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3972>
Otherwise application would not be able to know matching element
for wanted device. Typical use case of the read-only device path
(DXGI Adapter LUID, CUDA device index, etc) property is that
application enumerates physical devices and then selects matching
GStreamer element (in null state) via device path property.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4220>
If sticky events are present on parsebin source pads, we propagate them to the
multiqueue source pads. Those will be propagated on the new urisourcebin source
pads like in the other code paths.
This ensures that STREAM_START event are present on new source pads. If CAPS
event are also present (not guaranteed), they will also be available.
Fixes#2384
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4203>
H.265 NAL always have 2 bytes of headers. Unlike the H.264 parser, this parser
will simply return that there is NO_NAL if some of these bytes are missing.
This is then properly special cased by parsers and decoders. Add a test to
ensure we don't break this in the future.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3234>
The appropriate return value for incomplete NAL header should be
GST_H264_PARSER_NO_NAL_END. This tells the parser element to
gather more data. Previously, it would assume the NAL is corrupted
and would drop the data, potentially causing stream corruption.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3234>
The flowcombiner and active_streams shouldn't be cleared in the
mse-bytestream variant, only in the mss-fragmented one. Otherwise the
soft reset leaves qtdemux in a state where it still believes that it has
streams, but they've been cleared. In that case, a null pointer
dereference happens and the app crashes.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4199>
Previously, reassigning loop index l in nicestream.c
could cause a segfault if l->data was null, as it could
reassign l to a null variable, triggering the loop
postassignment l->next, which then segfaults due to
l now being null. It is instead moved into the loop.
_delete_transport already performs the reassignment
inline.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4192>
In gst_video_info_dma_drm_to_caps() the caps are newly created, so there's no
need for make it writable. In gst_video_info_dma_drm_from_caps() a copy of the
caps is done, which implies a gst_caps_make_writable().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4195>
In webrtc_data_channel_send functions, both data and string,
an early return on a non-open datachannel caused it to leak
the buffer used for pushing to appsrc, meaning any buffer
sent after leaving the open state was leaked in full.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4191>
When using such a launch line:
fakesrc ! "audio/x-opus, channel-mapping=(int)<0, 1>" ! fakesink
the caps string, with spaces escaped but no quotes gets passed to
gst_caps_from_string(), which then fails to parse the array because it
contains spaces.
When using an explicit capsfilter instead:
fakesrc ! capsfilter caps="audio/x-opus, channel-mapping=(int)<0, 1>" ! fakesink
the caps string, with spaces escaped and quotes gets passed through
gst_value_deserialize, which first calls gst_str_unwrap() on it and only
then gst_caps_from_string() on the result.
This fixes the inconsistency by using a custom version of str_unwrap()
in the parser, which doesn't expect a quoted string.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4181>
When copying a buffer, for example with gst_buffer_make_writable(), the
new buffer might reference the same GstMemory as the src buffer,
making those memories not writable. If the src buffer gets disposed
first it should return to its buffer pool, but since some of its
memories are not writable it gets discarded and new buffer/memory gets
allocated.
Solves this by making the new buffer keep a reference to the src buffer,
that ensures that by the time the src buffer gets disposed no other
buffer are referencing its memories and it can thus return safely to its
pool.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4176>
gst_buffer_add_parent_buffer_meta() is used when a GstBuffer uses
GstMemory from another buffer that was allocated from a pool. In that
case we want to make sure the buffer returns to the pool when the memory
is writable again, otherwise a copy of the memory is created. That means
the child buffer must drop its ref to the memory first, then drop the
ref to parent buffer so it can return to the pool when it is the only
owner of the memory.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4176>
This is already done for every other calls to send_packet. The deadlock occures
since FFMPeg 6.0. The decoder tries to get a buffer from a thread during
the draining process, and blocks trying to get the video decoder stream lock
already heald by the drain function.
Fixes#2383
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4171>
