Making the thread receiving the stats wait on the loop to respond was
not a good idea, as the latter can get blocked on the streaming thread.
Have get_stats read the values directly, adding a lock to ensure we
don't read garbage.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1550>
Ensure we take the object lock while accessing `GstElement.sinkpads`.
Use an iterator when the code isn't simple to avoid deadlock.
When we find the best pad, take a reference so a concurrent pad
release doesn't destroy the pad before we're done with it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1553>
There are quite a few reserved PID in the various MPEG-TS (and derivate)
specifications which we should definitely not use. Those PID have a certain
meaning and purpose.
Furthermore, a lot of the code in the muxer implementation also makes assumption
on the purpose of streams based on their PID.
Therefore, when requesting a pad with a specific PID, make sure it is not a
restricted PID.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1561>
Regardless if it's multicast or not, set the address property to match
the element address. This is the address of the interface to listen to,
which is expected to be ANY in most cases, but should be honnored even
for RTCP non-multicast case.
This also fixes an assertion if the address is not a parsable IPv4 or
IPv6 string.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1433>
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.
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>
Try to negotiate if the framerates on either sides of the interlace are
decided using capsfilters and the framerates are correct. Otherwise the
following pipelines would fail to negotiate:
gst-launch-1.0 videotestsrc !
video/x-raw,framerate=24/1,interlace-mode=progressive ! interlace
field-pattern=2 ! video/x-raw,framerate =30/1 ! fakesink
gst-launch-1.0 videotestsrc !
video/x-raw,framerate=60/1,interlace-mode=progressive ! interlace
field-pattern=0 ! video/x-raw,framerate=30/1 ! fakesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1349>
This reverts commit b75a61342f.
The parser would only set the mode to progressive or mixed, missing the
cases where it should have been interleaved. Interleaved is more
difficult to detect because in h264 it happens per frame. On the other
hand, h264 decoders detect the interlacing information per-frame and set
the caps correctly. By giving potentially incorrect interlacing
information in the parser already, it's being enforced downstream even
after decoding, breaking some use cases (e.g. an encoder can't properly
mark the stream as TFF or BFF). On the other hand, there's no valid use
case for having interlacing information on the caps at the parsing
stage, so after a lot of discussion, it was decided to revert this.
Initial commit message:
=========================
Those are the rules:
In the SPS:
* if frame_mbs_only_flag=1 => all frame progressive
* if frame_mbs_only_flag=0 => field_pic_flag defines if each frame is
progressive or interlaced, thus the mode is 'mixed' in GStreamer
terms.
https://bugzilla.gnome.org/show_bug.cgi?id=779309
=========================
Fixes#1313
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1335>
Add an element that converts AYUV video frames to a DVB
subpicture stream.
It's fairly simple for now. Later it would be good to support
input via a stream that contains only GstVideoOverlayComposition
meta.
The element searches each input video frame for the largest
sub-region containing non-transparent pixels and encodes that
as a single DVB subpicture region. It can also do palette
reduction of the input frames using code taken from
libimagequant.
There are various FIXME for potential improvements for now, but
it works.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1227>
If the src_peer_caps are EMPTY (e.g. negotiation failed somewhere), the
assertion inside gst_video_info_from_caps would fail and the whole
pipeline would crash. Check for gst_caps_is_empty before
gst_video_info_from_caps and gracefully fail if it's empty.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1333>
34af8ed66a changed the code to use the
packetizer's packets instead of the incoming buffers, but mpegtsbase
didn't actually push all packets to the subclass. As a result, padding
(PID 0x1FFF) packets got lost.
Add a new boolean to toggle pushing unknown packets to mpegtsbase and
have mpegtsparse make use of it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1300>
And also set/unset the RESYNC flag accordingly.
It can happen that the flag is preserved by GstAdapter from the input
buffer. For example if a big input buffer is split into many small ones,
each of the small ones would have the flag set.
All other buffer flags seem safe to keep here if they were set,
including the GAP flag.
Also ensure that the buffer is actually writable before changing any
flags or metadata on it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1298>
tsparse leaked input buffers quite badly:
GST_TRACERS=leaks GST_DEBUG=GST_TRACER:9 gst-launch-1.0 audiotestsrc num-buffers=3 ! avenc_aac ! mpegtsmux ! tsparse ! fakesink
The input_done vfunc was passed the input buffer, which it had to
consume. For this reason, the base class takes a reference on the buffer
if and only if input_done is not NULL.
Before 34af8ed66a, input_done was used in
tsparse to pass on the input buffer on the "src" pad. That commit
changed the code to packetize for that pad as well and removed the use
of input_done.
Afterwards, 0d2e908523 set input_done
again in order to handle automatic alignment of the output buffers to
the input buffers. However, it ignored the provided buffer and did not
even unref it, causing a leak.
Since no code makes use of the buffer provided with input_done, just
remove the argument in order to simplify things a bit.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1274>
We might have to drain already queued input based on the old segment
before forwarding the new segment event. The new segment is only
forwarded after a discont as otherwise we might cause unnecessary
timestamp jumps as we output buffers timestamped based on sample counts.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1254>
If the input has a miss-placed filler zero byte (e.g. a filler without a 4
bytes start code on the next NAL), we would endup using the same timestamp
twice. Ask the base class to read the timestamp from the buffer were the NAL
actually starts.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1251>
This will stop stripping four bytes start code. This was fixed and broken
again as it was causing the a timestamp shift. We now call
gst_base_parse_set_ts_at_offset() with the offset of the first NAL to ensure
that fixing a moderatly broken input stream won't affect the timestamps. We
also fixes the unit test, removing a comment about the stripping behaviour not
being correct.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1251>
The volatile is not needed here and causes compiler warnings
with newer GLib versions.
gstautoconvert.c: In function ‘gst_auto_convert_dispose’ (and elsewhere):
glib/gatomic.h:108:3: warning: initialization discards ‘volatile’ qualifier from pointer target type [-Wdiscarded-qualifiers]
gstautoconvert.c:224:24: note: in expansion of macro ‘g_atomic_pointer_get’
224 | GList *factories = g_atomic_pointer_get (&autoconvert->factories);
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1237>
