These null checkes are slightly misleading when double-checking
mutability for external language interop. None of the functions in
these files allow the variable at hand to become `NULL` under normal
operation, because they are checked at initialization and never (allowed
to be) reassigned to `NULL`.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1615>
When matching segments across playlists with Program-Date-Times,
use the difference in segment PDTs to adjust the stream time
that's being transferred. This can fix cases where the
segment boundaries don't align across different streams
and the first download gets thrown away once the PTS
is seen and found not to match.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3309>
Check whether the init file / MAP data for a segment
is different to the current data and trigger an
update if so. Previously, the header would only
be checked in HLS after switching bitrate or
after a seek / first download.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3307>
Previously the minimum buffering threshold was hardcoded to a specific
value (10s). This is suboptimal this an actual value will depend on the actual
stream being played.
This commit sets the low watermark threshold in time to 0, which is an automatic
mode. Subclasses can provide a stream `recommended_buffering_threshold` when
update_stream_info() is called.
Currently implemented for HLS, where we recommended 1.5 average segment
duration. This will result in buffering being at 100% when the 2nd segment has
been downloaded (minus a bit already being consumed downstream)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3240>
This is an additional quality parameter. In the default configuration this
quality switch is deactivated because it would cause a workload increase
which might be significant. If workload is not an issue in the application
it can be recommended to activate this feature.
A flush request is done when set_format is called to empty internal bit
buffer maintained by fdk-aac. When this happens, during the explicit
call to handle_buffer, decodeFrame does not return a AAC_DEC_OK. This
gets reported as a decoding error while no decoding error in fact took
place. Since this can be confusing, just return a GST_FLOW_OK and log
that an explicit flush was requested.
In order to figure out if the "raw" audio contained within the wav
container is actually DTS, right now we call the typefinder helper
which runs all typefinders.
Speed up this type finding process by specifying the extension.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3294>
GST_TRACERS="leaks" GST_DEBUG="GST_TRACER:7,leaks:6" gst-play-1.0 --use-playbin3 test.mkv
When running a pipeline like above, leaks are observed.
0:00:56.882419132 240637 0x5562c528ccc0 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstConcatPad, address=(gpointer)0x7efd7c0d20a0, description=(string)<'':sink_0>, ref-count=(uint)1, trace=(string);
0:00:56.882429131 240637 0x5562c528ccc0 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstConcatPad, address=(gpointer)0x7efd7c0d2be0, description=(string)<'':sink_0>, ref-count=(uint)1, trace=(string);
0:00:56.882437056 240637 0x5562c528ccc0 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstConcatPad, address=(gpointer)0x7efd7c0d3720, description=(string)<'':sink_0>, ref-count=(uint)1, trace=(string);
gst_element_release_request_pad does not unref the pad. It needs to
be followed by gst_object_unref. Doing that fixes the above leaks.
Use g_ptr_array_new_with_free_func with gst_object_unref as the free
function to unref the pad after release.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3177>
Posting latency messages causes a full and potentially expensive latency
recalculation of the pipeline. While subclasses should check whether the latency
really changed or not before calling this function, we ensure that we do not
post such messages if it didn't change.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3282>
The picture parameter picture->top_field_first is reused in this mode
to signal the TOP fields. As a side effect, it will change every frame
and current code assumed that if this changes then a renegotiation is
needed. Fixed this by ignoring that change whenever we are decoding one field
only.
Fixes#1523
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3276>
In fact, all the h264 bit writer have byte aligned output except
the slice header. So we change the API from bit size in unit to
byte size, which is easy to use. For slice header, we add a extra
"trail_bits_num" to return the unaligned bits number.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3193>
We use va pool as msdkvpp's bufferpool, which means both va memory
and dma memory will be allocated by va pool. Considering drm modifier
stuff is not ready, we use va memory with higher priortiry than
dma memory when deciding vpp caps.
Besides, this patch removes the specified "interlace-mode" in vpp caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3253>
The gap handling was in place, but there was no event handler to trigger it.
Implement the alpha sink event handler for the gaps. This fixes handling of
valid streams which may not refresh the alpha frames for every video frames.
It will also allow a clean error if the stream was missing the initial
alpha frame, at least until we find a better way to handle these
invalid frames.
Related to #1518
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3264>
Handle when encoder doesn't support rate control, which is set as
VA_RC_NONE, and if the set rate control mode is not supported by the
GStreamer element, the element configuration fails.
Also it logs out max and target bitrate.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3063>
The entrypoint is set when the encoder helper is constructed,
nonetheless it was also passed as parameter when opening. That's
buggy.
In order to simplify the code, the entrypoint at construction is
honored.
But gst_va_encoder_has_profile_and_entrypoint() now doesn't rely in
the internal list of profiles since it only contains those that
belongs to codec and entrypoint, thus it queries directly the VA
driver.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3063>
Need to put the actual profile in the output caps otherwise any
capsfilter after the encoder that was used to force the output
profile will fail, such as
fdkaacenc ! audio/mpeg,stream-format=adts,profile=he-aac-v1 ! ..
because we put profile=lc in there to match the profile signaled
in the ADTS header. This is expressed through the base-profile=lc
in the GStreamer caps though, the profile needs to carry the
'real' profile.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1785>
duplicate symbol '__invoke_on_main' in:
/Library/Frameworks/GStreamer.framework/Versions/1.0/lib/libgstvulkan-1.0.a(cocoa_gstvkwindow_cocoa.m.o)
/Library/Frameworks/GStreamer.framework/Versions/1.0/lib/libgstgl-1.0.a(cocoa_gstglwindow_cocoa.m.o)
ld: 1 duplicate symbol for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Also make the same change in iOS for consistency.
Continuation of https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1132
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3242>
segment events by demuxer.
In order to play nicely with `ffmpeg`, demuxers in `gst-libav` have to make
buffers available to `ffmpeg` while taking the blocking I/O model in `ffmpeg`
into account, which results in buffers not being sent downstream until `ffmpeg`
has processed them in its separate thread.
In constrast, many `gstreamer` events are simply forwarded downstream.
Currently `GST_EVENT_SEGMENT` events are forwarded downstream without any
processing, which can potentially result in:
* `GST_EVENT_SEGMENT` events being out of sync with buffers
* `GST_EVENT_SEGMENT` events going out that are incorrect because they apply
to data seen by the demuxer, but not necessarily seen by downstream elements
I came across this bug when I was attempting to enable G723.1 demuxing/decoding
using the G723.1 demuxer and decoder provided by `ffmpeg`. I wrote tests to
verify support for the functionality, and found that, in push mode,
`GST_EVENT_SEGMENT` events pushed to the demuxer by the upstream `filesrc`
element would be forwarded to the decoder without modification, resulting in
an internal data streaming error. With this patch, tests work in both push and
pull mode.
This patch solves the problem by disabling the forwarding of
`GST_EVENT_SEGMENT` events downstream (an initial `GST_EVENT_SEGMENT` event is
still pushed downstream by the demuxer). It's possible there's a better way to
do this, but, having looked at how a few different `gstreamer` demuxers deal
with `GST_EVENT_SEGMENT` events, it seems like the processing is somewhat
specific to the demuxer implementation, whereas `gst-libav` has one general way
of handling the situation for any `ffmpeg` demuxer. Perhaps there's a better
way to solve this using the `ffmpeg` API to take advantage of specific demuxer
details. IDK.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3218>
Add Windows Graphics Capture (WGC) API based screen capture mode.
The conditions where this mode is used:
* Explicitly requested by user (capture-api property)
* To capture specific window
* When DXGI desktop duplication API does not work on hybrid graphics systems
(e.g., multi-gpu laptop)
Full features of this implementation require Windows 11. And Windows 11
SDK is required to build this feature.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3144>
When the output alignment is smaller than the input alignment, for
example, When the output alignment is "FRAME" and the parse is likely
connecting to a decoder, the current PTS setting for AV1 frames inside
a TU is not very correct.
For example, a TU may begin with non-displayed frames and end with a
displayed frame. The current way will assign the PTS to the first
non-displayed frame, which is a decode-only frame and the PTS will be
discarded in the video decoder. While the last displayed frame has
invalid PTS, and so the video decoder needs to guess its PTS based on
the frame rate and previous frame's PTS. This is not a decent and
robust way. And more important, when the previous frames provide DTS,
the video decoder will also guess the PTS based on the previous frames'
DTS and trigger the warning like:
gstvideodecoder.c:3147:gst_video_decoder_prepare_finish_frame: \
<vavp9dec0> decreasing timestame
It sets the reordered_output and makes the decoder in free run mode.
We should correct the PTS for a TU, let the non-displayed frames have
no PTS while set the correct PTS to the displayed one. Also, when the
AV1 stream has multi spatial layers, there are more than one displayed
frames inside one TU with the same PTS.
Note: If the input alignment is not TU aligned, we can not know the
exact PTS of this TU, and so we just clear the PTS of the decode only
frame and leave others unchanged.
We also correct all the PTS if the output is OBU aligned. All their
PTS and DTS are set to the input buffer's PTS.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3182>
When the incoming data has big alignment than the output, we do not need to
call finish_frame() and exit the current handle_frame() for each splitted
frame. We can push them all at one shot with in one handle_frame(), whcih
may improve the performance and can help us to find the edge of TU.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3182>
These tests relied on setting the name of an element twice to verify
that the last one set took precedence, however name is a CONSTRUCT property
and the parser now errors out when such properties are set twice, in
g_object_new_with_properties .
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3026>
When trying to build the plugin, GCC starts complaining about issues
with one of the cdparanoia headers and it block us from being able
to build the plugin with Werror.
The current warning in the header look like this:
```
[1/2] Compiling C object subprojects/gst-plugins-base/ext/cdparanoia/libgstcdparanoia.so.p/gstcdparanoiasrc.c.o
In file included from ../subprojects/gst-plugins-base/ext/cdparanoia/gstcdparanoiasrc.h:37,
from ../subprojects/gst-plugins-base/ext/cdparanoia/gstcdparanoiasrc.c:31:
/usr/include/cdda/cdda_interface.h:164:3: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
164 | "Success",
| ^~~~~~~~~
...
/usr/include/cdda/cdda_interface.h:163:14: warning: ‘strerror_tr’ defined but not used [-Wunused-variable]
163 | static char *strerror_tr[]={
| ^~~~~~~~~~~
[2/2] Linking target subprojects/gst-plugins-base/ext/cdparanoia/libgstcdparanoia.so
```
Last release of cdparanoia was in 2008, so our best bet for the
time is to ignore the warnings.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2722>
This allows correct handling of wrapping around backwards during the
first wraparound period and avoids the infamous "Cannot unwrap, any
wrapping took place yet" error message.
It allows makes sure that for actual timestamp jumps a valid value is
returned instead of 0, which then allows the caller to handle it
properly. Not having this can have the caller see the same timestamp (0)
for a very long time, which for example can cause rtpjitterbuffer to
output the same timestamp for a very long time.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1500
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3202>
Adding loopback capture mode for specified PID.
Note that this feature requires Windows 10 build 20348
(Windows 11/Windows Server 2022 or later),
and any process loopback related properties will not be exposed
if OS does not support it.
Example launch lines:
* wasapi2src loopback-mode=include-process-tree loopback-target-pid=<PID>
Captures audio generated by an application (specified by PID)
and its child process
* wasapi2src loopback-mode=exclude-process-tree loopback-target-pid=<PID>
Captures desktop audio excluding PID and its child process
Fixes: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1278
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3195>
If there is an error while connecting, the streaming task will be stopped, and
is_running() will be false, causing a GST_FLOW_FLUSHING to be returned. Instead,
we perform the error check (!self->connection) first, to return an error if
that's what occured.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3189>
We've seen occasional crashes in the `wavparse` module associated with
referencing a buffer in `gst_wavparse_chain` that's already been freed. The
reference is stolen when the buffer is transferred to the adapter with
`gst_adapter_push` and, IIUC, assuming the source doesn't hold a reference to
the buffer, the buffer could be freed during interaction with the adapter in
`gst_wavparse_stream_headers`.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3179>
in certain ways.
In the case that a test is provided for, the size of the `fmt ` chunk is
changed from 16 bytes to 18 bytes (bytes 17 - 20 below):
```
$ hexdump -C corruptheadertestsrc.wav
00000000 52 49 46 46 e4 fd 00 00 57 41 56 45 66 6d 74 20 |RIFF....WAVEfmt |
00000010 12 00 00 00 01 00 01 00 80 3e 00 00 00 7d 00 00 |.........>...}..|
00000020 02 00 10 00 64 61 74 61 |....data|
00000028
```
(Note that the original file is much larger. This was the smallest sub-file
I could find that would generate the crash.)
Note that, while the same issue doesn't cause a crash in pull mode, there's a
different issue in that the file is processed successfully as if it was a .wav
file with zero samples.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3173>
When the alignment is "FRAME" and the parse is likely connecting to
a decoder, the current PTS setting for VP9 frames inside a super
frame is not very correct.
For example, the super frame may begin with non-displayed frames and
end with a displayed frame. The current way will assign the PTS to
the first non-displayed frame, which is a decode-only frame and the
PTS will be discarded in the video decoder. While the last displayed
frame has invalid PTS, and so the video decoder needs to guess its
PTS based on the frame rate and previous frame's PTS. This is not a
decent and robust way. And more important, when the previous frames
provide DTS, the video decoder will also guess the PTS based on the
previous frames' DTS and trigger the warning like:
gstvideodecoder.c:3147:gst_video_decoder_prepare_finish_frame: \
<vavp9dec0> decreasing timestame
It sets the reordered_output and makes the decoder in free run mode.
We should correct the PTS for a super frame, let the non-displayed
frames have no PTS while set the correct PTS to the displayed one.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3155>
The scenario is what we try in the tests:
- we have a segment with .stop set
- some frame(s) flow
- we get a CAPS event
- we get an EOS (before getting buffers after the CAPS event)
in that case, without that patch, the segment is not properly closed
which is not correct. In this patch we keep track of previous caps until
a new buffer arrives, this way in that situation we set previous caps
again, and close the segment with the previous buffer.
Fixes: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1352
in this specific case
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3059>
Apparently we cannot start sending messages from another datachannel
before the previous message was completely sent. usrsctplib will
complain about being locked on another stream id and set
errno=EINVAL.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2454>
The implementation was inconsistent between create and destroy. EGLImage
creation and destruction is requires for EGL 1.5 and up, while
otherwise the KHR version is only available if EGL_KHR_image_base
feature is set. Not doing these check may lead to getting a function
pointer to a stub, which is notably the case when using apitrace.
Fixes#1389
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2925>
The idea is to give the application the possibility to adjust the error
code when responding to a request. For that purpose the pipeline's bus
messages are emitted to subscribers through a signal handle-message.
The subscribers can then check those messages for errors and adjust
the response error code by overriding the virtual method
adjust_error_code().
Fixes#1294
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2972>
The order of the devices iterator from the SDK is undefined and can
randomly change.
Keep the device-number property for backwards compatibility and
simplicity but prefer the persistent-id property and also use it for the
device provider implementation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3078>
GstDXGIGetDebugInterface() is unused when targeting UWP. We directly
call DXGIGetDebugInterface1() in that case.
Fixes build failure:
../gst-libs/gst/d3d11/gstd3d11device.cpp(271): error C2440: '=': cannot convert from 'HRESULT (__cdecl *)(UINT,const IID &,void **)' to 'DXGIGetDebugInterface_t'
../gst-libs/gst/d3d11/gstd3d11device.cpp(271): note: This conversion requires a reinterpret_cast, a C-style cast or function-style cast
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3118>
According to W3C
specification (https://w3c.github.io/webrtc-pc/#datachannel-send) we
should return InvalidStateError exception when trying to send when the
channel is not open. In the world of C/glib/gstreamer we don't have
exceptions but have to rely on gboolean/GError instead. Introducing
these calls for a change in function signature of the action signals
used to send data on the datachannel. Changing the signature of the
existing "send-string" and "send-data" signals would mean an immediate
breaking change so instead we deprecate them. Furthermore, there is no
way to express GError** as an argument to an action signal in a way
that fits language bindings (pointer-to-pointer simply does not work)
and we have to use regular functions instead.
Therefore we introduce gst_webrtc_data_channel_send_data_full() and
gst_webrtc_data_channel_send_string_full() while deprecating the old
functions and corresponding signals.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1958>
Always hold a reference to the soft volume element
provided by the playsinkaudioconvert bin helper, the
same as when volume is provided by a sink element,
or the soft volume element gets unreffed too soon.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3108>
This is a regression that was introduced in
cca2f555d1 (yes, 9 years ago).
The only place where a demuxer streaming thread should be stopped is when the
sinkpad is deactivated from pull mode (i.e. PAUSED->READY).
Attempting to stop the task in this function would cause this to happen when a
FLUSH_STOP or STREAM_START event is received... which can cause deadlocks.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3109>
It would constantly want to renegotiate (and spam the debug log) even
though the channel layout hasn't actually changed. We use the same
fallback in gst_ffmpegauddec_negotiate() already.
This happens with WMA files for example.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3103>
We need to call this to register the MusixBrainz tags before we use
them in an XMP schema.
Fixes this critical when attempting to run jpegparse on a JPEG
containing MusicBrainz XMP tags:
GStreamer-CRITICAL **: 20:41:07.885: gst_tag_get_type: assertion 'info != NULL' failed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3092>
Currently if the user is not able to access the devices under /dev/media*,
either due to no media devices present on the system or simply no permission
to access the device, v4l2codecs initialises with no features or debug messages.
Since calling `GST_DEBUG="v4l2*:7" gst-inspect-1.0 v4l2codecs` is a typical way
to diagnose why element(s) failed to enumerate, we should be more verbose here
when the user is not able to access any /dev/media* device. So print a simple
debug message in this case to aid debugging.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3088>
The purpose of a deep buffer copy is to be able to release the source
buffer and all its dependencies. Attaching the parent buffer meta to
the newly created deep copy needlessly keeps holding a reference to the
parent buffer.
The issue this solves is the fact you need to allocate more
buffers, as you have free buffers being held for no reason. In the good
cases it will use more memory, in the bad case it will stall your
pipeline (since codecs often need a minimum number of buffers to
actually work).
Fixes#283
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2928>
Since commit a79a756b79 we could change to ignore-pcr automatically at 500ms
into a live stream when no PCR is seen by then. However the stream counting in
program change detection was wrongly considering ignore-pcr programs to have a
separate PCR PID, even though we are actually ignoring the PCR PID completely,
resulting in an erroneous program switch getting triggered from the different
stream count. This in turn would send an EOS and switch out the pads for what
actually is still the same program, while we intended to simply apply a
workaround for broken encoders.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3060>
If the SETUP request returns an IPv6 server address in the Transport
field, we would generate an incorrect URI, and multiudpsink would fail
to initialize:
```
rtspsrc gstrtspsrc.c:9780:dump_key_value:<source> key: 'Transport', value: 'RTP/AVP;unicast;source=fe80::dc27:25ff:fe5e:bd13:8080;client_port=62696-62697;server_port=4000-4001'
...
rtspsrc gstrtspsrc.c:4595:gst_rtspsrc_stream_configure_udp_sinks:<source> configure RTP UDP sink for fe80::dc27:25ff:fe5e:bd13:8080:4000
...
multiudpsink gstmultiudpsink.c:1229:gst_multiudpsink_configure_client:<udpsink0> error: Invalid address family (got 23)
```
We can't look at stream->is_ipv6 because we can't rely on the server
returning the right value there. In the issue reported about this,
server reported itself as `KuP RTSP Server/0.1`, and the SDP was:
```
c=IN IP4
m=video 54608 RTP/AVP 96
a=rtpmap:96 H264/90000
```
So we need to parse the string value and figure out the family
ourselves.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1058
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1819>
Fixes warning with meson 0.62:
gst-plugins-bad| subprojects/gst-plugins-bad/meson.build:546: WARNING:
Project targets '>= 0.62' but uses feature deprecated since '0.62.0':
pkgconfig.generate variable for builtin directories. They will be
automatically included when referenced
and more.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3086>
