When exporting a DMABuf from a VASurface the user might tell that the surface
was allocated with certain fourcc, but the returned VADRMPRIMESurfaceDescriptor
migth tell a different fourcc, as in the case or radeonsi driver, for duplicated
fourcc, such as YUY2 and YUYV.
Originally it was supposed to be a failed exportation. This patch relax this
validation by allowing different fourcc.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5760>
In multi-card scenario, user can set GST_MSDK_DRM_DEVICE env variable to
choose the device. This patch can align vpl's queried results with the
users' choice by passing deviceID when creating mfx implementation.
Co-authored-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5697>
This is a bit of a hack solution has I think the correct solution is to
expose model caps on sinkpad (eventually sinkpads). Till then I think
this is reasonable.
- Add a property to onnxinference to set datatype.
- Fix internal buffer allocation size based on datatype.
- Extract method to remove alphe channel and convert to planar image
when requested. Also template the method to support writing to buffers
of different datatype.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5761>
The `GstFlowCombiner` is responsible for tracking the flow of each
stream and handle the overal flow return value. Without that, we
can end up with the following scenario:
- Audio+video stream
- Only the video stream is linked downstream
- The audio stream goes EOS, video doesn't yet
-> We update the Flow in the combiner with OK as all streams are not EOS
- Video goes EOS because downstream returned EOS
-> `qtdemux` returns `FLOW_OK` forever because the unlinked audio pad
has `last_flowret==FLOW_OK`
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5724>
Windows does not support fork() so all tests will run in a single
process, and global variables will be reused across multiple tests.
Thus, each test should reset global variables.
Also, setup pad chain/event functions before playing state
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5752>
When requesting an asset from different threads we had no
guarantee that during the time we lookup an asset (which didn't exist)
and the time we create the asset with the same type/ID another thread
could not end up doing the same thing. In turns we could end up with
2 different threads loading the exact same asset and the cache
basically forgetting about one of the entries meaning that the user
would never get notified about one of those being ready to be used.
There was also the case when requesting "sync" where the user was
requesting an asset while another thread is creating it so it was
still in "ASSET_INITIALIZING" state, meaning that the returned asset
would be NULL which would be considered as an error in apps.
Since the cache lock is recursive we can just take it during the whole
ges_asset_request_async call and have other method still hold it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5732>
There is an existing PMT mapping between PCR_%s and an mpegtsmux sink
pad name, where %s equals the program number that the PCR corresponds
to. We re-purpose this functionality to also support a mapping between
PCR_%s and an arbitrary PID. If this mapping is set, then the header PCR
PID is set to this value, and PCR is attached to the stream with this
PID.
Note: the current implementation also attaches PCR to the video stream,
so this may be inefficient.
Co-authored-by: Jordan Yelloz <jordan.yelloz@collabora.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5726>
Clip tile rows and cols to 64 as describe in AV1 specification
to avoid writing outside array range but preserve sb_cols
and sb_rows value which are used to futher computation.
Fixes ZDI-CAN-22226 / CVE-2023-44429
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5702>
