A DPB buffer held by codec picture object may not be writable
at the moment, then gst_buffer_make_writable() will unref passed buffer.
Specifically, the use after free or double free can happen if:
* Crop meta of buffer copy is required because of non-zero
top-left crop position
* zero-copy is possible with crop meta
* A picture was duplicated, interlaced h264 stream for example
Interlaced h264 stream with non-zero top-left crop position
is not very common but it's possible configuration in theory.
Thus gst_buffer_make_writable() should be called with
GstVideoCodecFrame.output_buffer directly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6706>
The goal of this code was, for programs which were updates (i.e. adding/removing
streams but not completely changing) to allow dynamic addition/removal of
streams without completely removing everything.
But this wasn't 100% tested and there are a bunch of issues which make it fail
in plenty of ways.
For now disable that feature and force the legacy "add all pads again and then
remove old ones" behaviour to make it switch.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6651>
In addition to device removed status monitoring in gst_d3d11_result()
method, if ID3D11Device4 interface is available,
an event handle will be used for device removed status update.
And "device-removed" signal is removed since applications can monitor
the device removed status via gobject notify
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6699>
Adding new property in order to notify users of device removed status.
Once device removed status is detected, application should release
all ID3D12Device objects corresponding to the adapter, including
GstD3D12Device object. Otherwise D3D12CreateDevice() call for the
adapter will fail.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6699>
It seems that when D3D11CreateDevice collides in time
with other D3D11 calls, in particular the proccess of
creating a shader, it can corrupt the memory in the driver.
D3D11 spec doesn't seem to require any thread safety from
D3D11CreateDevice. Following MSDN, it is supposed to be called
in the beginning of the proccess, while GStreamer calls it with each
new pipeline.
Such crashes in the driver were frequently reproducing on the
Intel UHD 630 machine.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6686>
We suspect that it's not thread safe to just create and
destroy the device from any thread, particularly because
of D3D11CreateDevice, that is not documented as thread-safe.
While D3D11CreateDevice is usually protected from outside
by the gst_d3d11_ensure_element_data, it still can cross
with the Release() method of another device.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6686>
If propose_allocation comes before set_caps, self->video_info
has not been extracted from caps and self->video_info.size is 0.
It causes buffer pool fail to set config . So need to use info
size got from query instead when propose_allocation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6666>
Otherwise, if we run in to the copy case, this can cause these
groups to stay around with queued flag set, but never actually
queued, until gst_v4l2_allocator_flush() is called, which then
erroneously frees the associated memories, causing the release
function to decrement the allocator refcount where it was never
incremented, resulting in early allocator disposal, and either
deadlock or use after free.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6552>
Clarify the fact that `encodebasebin->src_pad` is set when using a static source
pad (`encodebin`) and when not set it's dynamically added source
pads (`encodebin2`).
Fixes usage of encodebin2 when profiles are updated
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6667>
The caps obtained from parsing the allocation query is borrowed and
should not be unreffed. This fixes criticals assertion introduced in
1.24.1.
(gst-launch-1.0:242): GStreamer-CRITICAL **: 19:48:02.667:
gst_mini_object_unref: assertion 'GST_MINI_OBJECT_REFCOUNT_VALUE (mini_object) > 0' failed
Fixes: 5189e8b956 ("v4l2codecs: decoders: Add DMA_DRM caps support")
Closes#3462
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6679>
We used to only track the first one but this was wrong, so we start
tracking all the children properties here, adapting the test which
was already thought for this to be implemented.
At the same time add some flags to determine how children properties
need to be handled adding a mode that means that all duplicated
children props will be set together when the user sets that particular
child property. This is going to be tested in a following commit.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/918>
Some decoder drivers need to wait enough capture buffers before
starting to decode. But the dequeued buffer flag LAST but empty
has no chance to queue back to driver, which makes decode hang
after seek. So need to queue back such kind of buffer to driver.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6579>
Output buffers don't have to be writable. Accepting read-only buffers
from the V4L2 buffer pool allows upstream elements to write directly
into the V4L2 buffers without triggering a CPU copy into a new buffer
from the same V4L2 buffer pool every time.
Tested with the vivid output device:
GST_DEBUG=GST_PERFORMANCE:7 gst-launch-1.0 videotestsrc ! v4l2sink device=/dev/video5
With this change, gst_v4l2_buffer_pool_dqbuf() must be allowed to not
resize read-only memories of output buffers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6572>
../subprojects/gst-plugins-bad/tests/check/libs/gstlibscpp.cc:41:
fatal error: gst/mpegts/gstmpegts-enumtypes.h: No such file or directory
Could only pass the needed deps to the libscpp test, but gets
messier to maintain, so let's at it for consistency.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6643>
