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>
A pipeline like this:
closedcaption/x-cea-708,format=cdp,framerate=30000/1001 ! ccconverter ! closedcaption/x-cea-708,format=cc_data
would produce a critical/assert:
GStreamer-CRITICAL **: 14:21:11.509: gst_util_fraction_multiply: assertion 'a_d != 0' failed
because there would be no framerate field on ccconverter's output.
Fixed by always fixating a framerate if the input has a framerate.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1393>
Unclear why hotdoc wants 'gstavtp' as the plugin name here,
that's just wrong.
Add since marker and mark private subclasses as plugin API
so hotdoc knows they belong to the plugin and aren't external.
Fix GstAvtpAafTstampMode get_type() function.
