... if target OS version was specified as Windows 10.
When enabled, desktop application can select target capture
implementation between WinRT and Win32
via GST_USE_MF_WINRT_CAPTURE environment
(e,g., GST_USE_MF_WINRT_CAPTURE=1 for WinRT impl.).
Default is Win32 implementation in case of desktop target.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1434>
... and do more strict validation for num_tile_columns_minus1 and
num_tile_rows_minus1.
As per specification Table A.8, allowed maximum number of tile rows
and tile columns are 22 and 20, respectively. So we should adjust the size
of each array.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1372>
Because the valid input formats for screen content coding extension is
a subset of input formats for range extension, user must specify the
profile for screen content coding extension in the caps filter
Example:
gst-launch-1.0 videotestsrc ! video/x-raw,format=NV12 ! msdkh265enc
low-power=1 ! video/x-h265,profile=screen-extended-main ! fakesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1389>
Previously, "en" (should have actually been "eng") was assumed
for the ISO-639 language descriptor if no language was explicitely given.
Neither ETSI EN 300 468 nor ATSC A/52 mandate for a language descriptor,
so we should simply not set it, if it's unknown.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1386>
The audio/mpeg,mpegversion=2 caps in GStreamer refer to
MPEG-2 AAC (ISO 13818-7), not to the extended MP3 (ISO 13818-3),
which is audio/mpeg,mpegversion=1,mpegaudioversion=2/3
Fix the caps, and add handling for MPEG-2 AAC in both ADTS and raw
form, adding ADTS headers for the latter.
meson.build:58: WARNING: The variable(s) 'waylandlibdir' in the input file 'subprojects/gst-plugins-bad/pkgconfig/gstreamer-plugins-bad-uninstalled.pc.in' are not present in the given configuration data.
We don't provide a .pc file for this lib nor install its headers,
so no need for this path to be in the uninstalled .pc file really.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1417>
rtpbin can still emit signals when it is being disposed, and while
rtpbin is inside ristsrc/ristsink it can still live longer.
So we either have disconnect all signals at some point, or let GObject
take care of that automatically.
Related to !1412
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1413>
rtpbin can still emit signals when it is being disposed, and while
rtpbin is inside rtpsrc/rtpsink it can still live longer.
So we either have disconnect all signals at some point, or let GObject
take care of that automatically.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1412>
With the asynchronous slice decoding, we only queue up to 2 slices
per frames. That side effect is that now we are dequeuing bitstream
buffers in both decoding and presentation order. This would lead to
a bitstream buffer from a previous frame being dequeued instead of
the expected last slice buffer and lead to us trying to queue an
already queued bitstream buffer.
We now fix this by tracking pending requests. As request are executed
in decoding order, we marking a request done, we can effectively
dequeue bitstream buffer from all previous request, as they have been
executed already.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1395>
The decoder is not being access from multiple threads, instead it is
always protected by the streaming lock. For this reason, a
GstAtomicQueue for the request pool is overkill and may even introduce
unneeded overhead. Use a GstQueueArray in replacement, the
GstQueueArray is a good fit since the number of item is predictable and
unlikely to vary at run-time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1395>
In slice mode, we'll do one request per slice. In order to recycle
bitstream buffer, and not run-out, wait for the last pending
request to complete and mark it done.
We only wait after having queued the current slice in order to reduce
that potential driver starvation and maintain performance (using dual
buffering).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1395>
