Latest MSYS2 MinGW provides these now, so we don't need to define them
if they're already present in the header.
The AudioClient3 GUID requires the Windows 10 SDK, so it's only
available in the latest MinGW, and the MinGW in Cerbero is too old.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5155>
VA decoders implementation has been verified from 1.18 through 1.22
development cycles and also via the Fluster test framework. Similar
to other cases, we can prefer hardware over software in most cases.
At the same time, GStreamer-VAAPI decoders are demoted to NONE to
avoid collisions. The first step to their deprecation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2312>
These 10bit formats are identical to NV12_16L32S, but 64bytes of data is being
prefixed with 16bytes data with four pixels of lower 2bits per byte. For
MT2110T, the lower two bits set so each bytes contains a column of 4 pixels,
also describe as tiled lower 2 bits. MT2110T has been chosen as a name to match
the vendor chosen name. This format is unlikely to exist for other vendors.
For MT2110R, the 2 low bits are in raster order.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3444>
There is currently no way for applications to know if the stream has
been properly terminated by the server or if the network connection
was disconnected as EOS is sent in both cases.
Adding a property so connection errors can be reported as errors
allowing applications to distinguish between both scenarios.
Fix#2828
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5115>
Pass GstVideoInfoDmaDrm or GstVideoInfo whenever possible, avoiding passing
strange combination of GstVieoFormat + modifier. Even though we don't have any
at the moment, this also allow supporting GstVideoFormat that are not supported
in our DRM integration.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5120>
According to libva API description, cu_qp_delta in VAConfigAttribValEncHEVCFeatures
is supposed to be used as a flag not the value of depth. And if flag enabled,
diff_cu_qp_delta_depth should be decided by log2_diff_max_min_luma_coding_block_size.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5068>
Rework the va_map_unlocked() after we keep mapping behavior (whether to
use derive) consistent with allocator_try stage. Also remove the flag
for iHD case because pitch/stride difference between vaCreateImage and
vaDeriveImage only possibly happen on iHD by now.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5046>
In gst_va_allocator_try, the first try is to use derive_image, if it
succeeds, we should use info from derived image to create bufferpool.
If derive fails, then try create_image and give created image info
to the pool.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5046>
vtenc has an async output queue, which we only iterate over after another frame is enqueued.
At the very least it means we're always a frame behind the fastest possible output.
In edge cases it's also bug-prone - for example if we only have 1 frame, the downstream caps negotiation
will never happen.
This commit adds a separate task running on the source pad, which only iterates over the output queue
and pushes frames out as soon as they're put there. The queue length is limited to ensure we don't encode
too far ahead compared to what downstream can consume. Any failures that occur when pushing data downstream
will be signalled in self->downstream_ret so that other parts of code can act accordingly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4967>
Sending an EOS event is actually really bad because rtpbin doesn't
handle that very well. It was only being used as a way to notify
webrtcbin to check if re-negotiation is needed.
We don't need that anymore, since changing the direction is enough to
notify webrtcbin to check for re-negotiation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5045>
lc3enc:
- encodes raw audio into lc3 format
- uses the default bitrate property and frame duration
from the caps to determine the byte count of
the encoded frames if it is not specified in
the downstream caps after negotiation
- uses the same byte count value for all the channels
- all the common session configuration parameters
are passed in the src caps
lc3dec:
- decodes an lc3 encoded audio
- sink caps should contain all the common session configuration
params
- uses frame_duration and frame_bytes (byte count) in the sink
caps as parameters along with sample rate and channel count
- byte count is same for all the channels
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4376>
`srt_rejectreason_str` doesn't give us a unique string for every
possible reason. Peers can define their own reasons and SRT just gives
us the string `"Application-defined rejection reason"` for all of them.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4948>
Adding new subtitle overlay element. It's a bin which is wrapping
two internal elements dwritesubtitlemux and dwritetextoverlay.
* dwritesubtitlemux: A new internal element to aggregate subtitle
buffers and to attach the aggregated subtitle buffers on
video buffer as meta.
* dwritetextoverlay: Extracts/renders the subtitle meta and
discard the meta after rendering.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4934>
There's no reason to release GstMemory manually at all.
If we do release GstMemory, corresponding GstBuffer will be
discarded by GstBufferPool baseclass because the size is changed
to zero.
Actual cause of heavy CPU usage in case of fixed-size pool
(i.e., decoder output buffer pool) and if we remove GstMemory from
GstBuffer is that GstBufferPool baseclass is doing busy wait in acquire_buffer()
for some reason. That needs to be investigated though, discarding
and re-alloc every GstBuffer is not ideal already.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4935>
The current way of using gst_video_info_set_format() will change all
fields of the GstVideoInfo. We only need to change its format, stride
and offset fields.
In order to keep the consistency with th common drm API, we rename the
gst_va_video_info_from_dma_info() into gst_va_dma_drm_info_to_video_info().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4883>
The current way only selects the best video format from the first
structure of the caps. The caps like:
video/x-raw(memory:VAMemory),drm-format=(string)NV12; \
video/x-raw(memory:VAMemory),format=(string){ NV12, Y210 }
Will just choose NV12 as the result, even the bitstream is 10 bits.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4928>
As VK_FORMAT_FEATURE_2_xxx are defined as static const variable, the
vscoce C compiler prevents the initialization of the vk_usage_map
structure with error "C2099: initializer is not a constant".
Init the structure separately.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4904>
The current way of using parent's copy_metadata() virtual function will
selectively filter out some meta such as crop meta. That virtual function
should be used when copying input buffer's meta data into output buffer,
not suitable when importing the input buffer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4887>
When the input buffer has crop meta, and we need to do copy, we
should consider the uncropped video size and copy the full size
of video memory.
The video meta in this case should contain the full uncropped
resolution info. We can use it to create full size va buffers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4887>
Adding Direct3D11 backend Qt6 QML videosink element, qml6d3d11sink.
Implementation details are similar to the qt6 plugin in -good
but there are a few notable differences.
* qml6d3d11sink accepts all GstD3D11 supported video formats (e.g., NV12).
* Scene graph (owned by qml6d3d11sink) will hold dedicated and sharable
RGBA texture which belongs to Qt6's Direct3D11 device, instead of sharing
GStreamer's own texture with Qt6.
* All rendering operations will be done by using GStreamer's Direct3D11 device.
Specifically, upstream texture will be copied (in case of RGBA)
or converted to the above mentioned Qt6's sharable texture.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3707>
Now all codec baseclasses can inform subclasses of correct max DPB size,
and exception handling (e.g., emergency bumping in h.264) has been
improved as well. Smaller number of additional DPB frame allocation
seems to be safe.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4878>
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>
If two senders use the same multicast IP and port then new_session_pad()
may try to add a srcpad to the same stream twice.
stream->srcpad is updated but gst_element_add_pad() fails the second
time. As a result stream->srcpad points to a deleted object and
access in gst_sdp_demux_stream_free() fails with a segfault.
Just ignore the second pad. Nothing useful can be done with it anyway.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4603>
The `gst_video_decoder_negotiate_pool` function expects the
`decide_allocation` function to always provide a pool and will fail to
negotiate if the pool is missing. If we return immediately (even if we
don't need to do anything special) negotiation will fail if the
downstream element does not propose a pool.
Fix by chaining up to the default `decide_allocation` function which
adds a fallback pool if one was not already proposed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4630>
Adding DirectWrite text rendering elements
* dwriteclockoverlay: Equivalent to clockoverlay
* dwritetimeoverlay: Equivalent to timeoverlay
* dwritetextoverlay: Similar to textoverlay but subtitle is not
supported
Newly added elements support system memory and d3d11 memory
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4826>
This new property allows setting of PES stream number for AAC audio
and AVC video streams.
The stream number is subject to the following constraints:
1. it must be between 0 and 15 for video
2. it must be between 0 and 31 for audio
Currently the PES stream number is hard-coded to zero for these
stream types.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4822>
Add support for 10/12/14/16 bit depths . This consists of multiple parts.
First is the parsing of caps, which pulls out the bitness and endianness
from the video/x-bayer format.
Second, gst_bayer2rgb_split_and_upsample_horiz() is split into two similar
functions, one for 8bit bayer handling and another for 16bit bayer handling.
The content is basically identical, except one uses 8bpp and the other 16bpp
inputs and outputs, and they each use different ORC code to match. The 16bpp
variant also handles endian swapping. There is now a wrapper called
gst_bayer2rgb_split_and_upsample_horiz() which selects the correct function
based on bpp from the parser.
Third, gst_bayer2rgb_process() is extended to handle both 8bit and 16bit
bayer data. Yet again there are matching ORC functions to handle the 16bit
data. This time however the 16bit handling of data is slightly special. The
ORC is not able to emit opcodes for 'x2 mergelq', so the trick here is to
store the BG and GR longs into separate 'dtmp' temporary buffer, and then
do one more ORC post-processing step, compensate for the less-than-16bpp
bitness using left shift, and reorder them into the destination frame
using 'mergelq' .
Example usage:
```
$ gst-launch-1.0 videotestsrc ! \
video/x-bayer,width=512,height=512,format=bggr16le ! \
bayer2rgb ! \
video/x-raw,format=RGBA64_LE ! \
videoconvert ! \
autovideosink
```
Example usage:
```
$ gst-launch-1.0 videotestsrc ! \
video/x-raw,width=512,height=512,format=ARGB ! \
rgb2bayer ! \
video/x-bayer,format=bggr12le ! \
bayer2rgb ! \
video/x-raw,format=RGBA64_LE ! \
videoconvert ! \
autovideosink
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
Add comments regarding which LINE()s point to which data in the
temporary buffer and a large comment explaining how the buffer
is processed. This will hopefully be useful to someone, as the
code is not obvious. No functional change.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
Instead of passing a single element of GstBayer2RGB structure into the
gst_bayer2rgb_split_and_upsample_horiz(), pass the entire pointer and
let the funciton pick out whatever it needs out of the structure. This
is a preparatory patch. No functional change.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
Pass all three parameters used by the LINE() macro to the LINE() macro
and unroll the code for readability. Add more comments regarding which
of these LINE()s point to which data in the temporary buffer to make
the code less confusing.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
The j variable is used as an iterator further down in this code, but
here it can be just inlined in the macro parameters to make the code
easier to read. This is done in preparation for further changes. No
functional change.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
The bayer2rgb process implemented doesn't support in-place tranform.
This element doesn't implement a "transform_ip" vmethod of
GstBaseTransform it will revert to using the "tranform" vmethod.
It's misleading to set it to TRUE, here. Change this to FALSE.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
Add support for conversion to 10/12/14/16 bit bayer pattern.
The implementation is rather simplistic, just take the ARGB
input, generate 16-bit data out of it instead of 8-bit, shift
them as required by the output bitness, and apply endian swap.
Example usage:
```
$ gst-launch-1.0 videotestsrc num-buffers=1 ! \
video/x-raw,width=512,height=512,format=ARGB ! \
rgb2bayer ! \
video/x-bayer,format=bggr12le ! \
filesink location=/tmp/bayer12.raw
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
Even if we don't yet know what the echo probe format is, we want to be able to
provide silence for the reverse path, so that when the probe becomes available,
there is no ambiguity around what time period the new set of samples are for.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4849>
The probe's info may not precisely match the dsp's info. For instance,
the number of channels or their layout might be different.
```
GStreamer-Audio-CRITICAL **: 16:21:32.899: the GstAudioInfo argument is not equal to the GstAudioMeta's attached info
```
This broke in d5755744c3.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4849>
A race condition can occur in `srtpdec` during the READY -> NULL transition:
an RTCP buffer can make its way to `gst_srtp_dec_chain` while the element is
partially stopped, resulting in the following critical warning:
> Got data flow before segment event
The problematic sequence is the following:
1. An RTCP buffer is being handled by the chain function for the
`rtcp_sinkpad`. Since, this is the first buffer, we try pushing the sticky
events to `rtcp_srcpad`.
2. At the same moment, the element is being transitioned from PAUSED to READY.
3. While checking and pushing the sticky events for `rtcp_srcpad`, we reach the
Segment event. For this, we try to get it from the "otherpad", in this case
`rtp_srcpad`. In the problematic case, `rtp_srcpad` has already been
deactivated so its sticky events have been cleared. We won't be pushing any
Segment event to `rtcp_srcpad`.
4. We return to the chain function for `rtcp_sinkpad` and try pushing the
buffer to `rtcp_srcpad` for which deactivation hasn't started yet, hence the
"Got data flow before segment event".
This commit:
- Adds a boolean return value to `gst_srtp_dec_push_early_events`: in case the
Segment event can't be retrieved, `gst_srtp_dec_chain` can return an error
instead of calling `gst_pad_push`.
- Replaces the obsolete `gst_pad_set_caps` with `gst_pad_push_event`. The
additional preconditions checked by previous function are guaranteed here
since we push a fixed Caps which was built in the same function.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4844>
A race condition can occur in `srtpdec` during the READY -> NULL transition:
an RTCP buffer can make its way to `gst_srtp_dec_chain` while the element is
partially stopped, resulting in the following critical warning:
> assertion 'parent->numsinkpads <= 1' failed
This can occur when the first RTCP buffer is received during the READY -> NULL
transition. If deactivation of the `rtp_srcpad` has already reached
`post_activate`, the sticky events are removed from this Pad. In this case,
`gst_srtp_dec_push_early_events` branches to the generation of a stream id
using `gst_pad_create_stream_id`. This function ensures that the element
doesn't own more than 1 sink pad. Since `srtpdec` owns two of them, the
assertion fails.
This commit uses `gst_element_decorate_stream_id` which doesn't perform this
check. The preconditions is not necessary in this particular context since the
stream id for the RTP / RTCP pads are derived from the same id.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4844>
Change the internal GstVideoInfo structure in the GstVaDmabufAllocator to
GstVideoInfoDmaDrm in order to keep track of the exported DRM format by the
driver, and thus removing the DRMModifier quark attached as qdata in the
GstMemory. Though, the exposed API isn't updated yet; that has to go in a
second iteration.
Also this patch clean up some code (remove an unused buffer size assignation)
and fix some typos in documentation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4821>
The VA has its internal video format mapping(because different drivers may
have different interpretation for the same format), so we should convert the
info in GstVideoInfoDmaDrm into the according video info based on that mapping.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4821>
Some surface formats such as GST_VIDEO_FORMAT_Y42B and GST_VIDEO_FORMAT_RGB
can be created but can not be exported as DMA buffer. You can not say that
this is a driver bug because the driver may never want to share this kind of
surface out of libva.
And this function will be used to detect modifiers later, so the error message
will be annoying.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4821>
The proxy callback for the notify::last-message was emiting the signal
again on the child, which caused an infinit loop. We could swap the child
and the user data to signal to the bin instead, but it was found that proxying
this signal was not very useful. Typical use case it to set silent=0 and use
deep-notify feature. Proxying that signal just duplicate that output which
isn't very useful.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4766>
Decoder bounded CUDA memory is allocated by driver and the pool size
is fixed. Since we don't know how many buffers would be held by
downstream non-CUDA element, we should download such CUDA memory
and release it back to decoder.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4810>
Currently the uvcsink is only capable to run in an application
that is handling the state transitions of the pipeline properly
by checking on streaming event from the uvcsink.
This code is improving the element by adding an fakesink to
consume possible videostream flow in case the pipeline state
is not changing on hosts streamoff.
This is helpfull when using local gst-launch pipelines where
the streaming event is not monitored to change the pipelines
state.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1304>
This patch adds an element to stream video data to an uvc video gadget.
The element handles the uvc events STREAMON, STREAMOFF, SETUP and DATA.
to start, stop and configure the video buffer flow by the use of pad
probes. It works with linux kernels of versions higher than v6.1.
The element makes use of the v4l2sink proxy property v4l2sink::device
to locate the corresponding device to parse the configfs for additional
data.
The code in uvc.c is basically derived from /lib/uvc.c in
https://git.ideasonboard.org/uvc-gadget.git.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1304>
Updated API usage appropriately, and now we have a versioned package to
track breaking vs. non-breaking updates.
Deprecates a number of properties (and we have to plug in our own values
for related enums which are now gone):
* echo-suprression-level
* experimental-agc
* extended-filter
* delay-agnostic
* voice-detection-frame-size-ms
* voice-detection-likelihood
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2943>
Allow a project to use gstreamer-full as a static library
and link to create a binary without dependencies.
Introduce the option 'gst-full-target-type' to
select the build type, dynamic(default) or static.
In gstreamer-full/static build configuration gstreamer (gst.c)
needs the symbol gst_init_static_plugins which is defined
in gstreamer-full.
All the tests and examples are linking with gstreamer but the
symbol gst_init_static_plugins is only defined in the gstreamer-full
library. gstreamer-full can not be built first as it needs to know what plugins
will be built.
One option would be to build all the examples and tests after
gstreamer-full as the tools.
Disable tools build in subprojects too as it will be built at the end of
build process.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4128>
The `switch (n_rear)` supports up to 5 rear channels, but our channel
set only had space for 3. Size the set properly to fix this.
This didn't actually cause any memory unsafety as `PUSH_CHAN` would stop
incrementing `n_rear` if the channel set is already full.
Thanks to @alatiera for noticing this.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4712>
adjust log level from GST_ERROR to GST_WARNING when h264 caps have
codec_data but no avc format or have no codec data or stream-format.
Because theses are not real errors, it is easy to mislead if print error
logs.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4675>
The resolution of VP9 video can be changed without keyframe.
The change detected by MSDK/VPL should be negotiated with downstream.
Only the situation can be fixed here if the changed resolution is less than or equal to the initial surface resolution.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4450>
New vulkan formats don't match the number of planes with the number of memories
attached to the buffer. This patch changes the pattern of using planes for
traverse the memories with the number of attached memories.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
It's a generalization of the original gst_vulkan_get_or_create_image_view().
The reason for passing the whole VkImageViewCreateInfo structure rather than
just the missing fields, is because VkImageSubresourceRange and
VkComponentMapping can be different and those are most of VkImageViewCreateInfo.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
This is going to be used when the pool is used by a video decoder for
VK_IMAGE_USAGE_VIDEO_DECODE_DST_BIT_KHR, since the frame allocation needs the
VkVideoProfileInfoKHR, and for that here GstCaps is used to wire it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
The specification says:
VUID-vkAllocateMemory-pAllocateInfo-01713
must pAllocateInfo->allocationSize be less than or equal to
VkPhysicalDeviceMemoryProperties::memoryHeaps[memindex].size where memindex =
VkPhysicalDeviceMemoryProperties::memoryTypes[pAllocateInfo->memoryTypeIndex].heapIndex
as returned by vkGetPhysicalDeviceMemoryProperties for the VkPhysicalDevice that
device was created from.
Though this can be catch by the validation layer, the requested frame size
depends on the use case so it's better to check this restriction by our code.
This patch also makes use of this new function to find memory type index,
and removes the unused function to find memory type index, which, as GstVulkan is
considered unstable, we can do it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
The purpose of this function is to get more info about the mapped Vulkan format
from the GStreamer format, since they can be multiple Vulkan formats for one
GStreamer format.
Also a Vulkan format may have certain usage and aspects that must be verified.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
