The current way of dma caps uses the drm-format to replace the orginal
format field. The absence of format field means it can accept all formats.
It causes problems when clipping with other old DMA or video/x-raw(ANY)
caps, the result will contain both format field and drm-format field,
which is not valid DMA caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4981>
This GST_VIDEO_FORMAT_DMA_DRM is introduced for DMABuf kind feature
usage. It represent the DMA DRM kind memory. And like the ENCODED
format, it should not be interpreted and mapped as normal video format.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4981>
Adding GST_CUDA_CRITICAL_ERRORS env variable so that program can be
terminated on unrecoverable error.
Example)
GST_CUDA_CRITICAL_ERRORS=2,700 gst-launch-1.0 ...
In this example, CUDA_ERROR_OUT_OF_MEMORY(2) and
CUDA_ERROR_ILLEGAL_ADDRESS(700) are registered as critical error
and program will be aborted on those errors
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4729>
Previously it was possible that a shared media was just in the process
of being unprepared because the last client disappeared, while another
client retrieved it from the cache and then tried to use it. Unless the
media was reusable this would've then failed unnecessarily.
To avoid this it is necessary to lock the media directly in
gst_rtsp_media_factory_construct() and return a locked media. After
locking the cached media it is necessary to check if the media was ever
unprepared or is actually reusable and based on that either reuse it or
create a new media.
This minimally changes the gst_rtsp_media_factory_construct() API to
always return a locked media, and adds a new
gst_rtsp_media_can_be_shared() function to check if a media can actually
be shared in practice.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4606>
check_version(1.23.1) would return TRUE for a git development version
like 1.23.0.1, which is quite confusing and somewhat unexpected.
We fixed this up in the version check macros already in !2501, so this
updates the run-time check accordingly as well.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4513>
Allowing better control over the way discovery happens and allowing
us to expose a proper API.
This also adds the potential of implementing more multi-threaded
discovery in a clean way in the future.
This allows us to cleanly expose the new
GstDiscoverer::load-serialize-info signal.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3911>
