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>
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>
../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>
When using v2.0.2 of the subproject, it triggers werror for
unused functions that come from the fdkaac headers.
This avoids errors like the following when werror is set.
```
subprojects/fdk-aac-2.0.2/fdk-aac/FDK_audio.h:757:29: error: ‘FDKlibInfo_lookup’
defined but not used [-Werror=unused-function]
757 | static FDK_AUDIO_INLINE INT FDKlibInfo_lookup(const LIB_INFO* info,
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6611>
Fix
gstanalyticsmeta.c:134: Warning: GstAnalytics: "@instance"
parameter unexpected at this location
warning (caused by the extraneous empty line in the doc chunk)
and align function arguments with documentation and header file
(handle -> instance).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6585>
For some cameras `gst_jpeg_parse_app0()` fails on a invalid segment.
While this is likely a driver or firmware bug that should be addressed
accordingly, it's not fatal and likely does not deserve a bus message on
every frame, flooding journals.
Turn down the volume of the warnings by turning them into object
warnings. If we conclude that in some cases we'd still want bus
warnings, they can be done more fine-grained in the
`gst_jpeg_parse_appX()` functions.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6490>
