For VPS, PPS, APS, OPI and DCI, the extension flags are the last syntax
in the structures, and according to the spec, should be ignored if set to 1.
Therefore, we can just ignore them rather than failing.
This fixes a few failures in fluster, like in the PSEXT_A_Nokia_2 stream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8359>
If we find VPS/SPS/PPS in codec_data and call gst_h266_parse_process_nal
with them, we need to have negotiated before in order to correctly
process them with flags like h266parse->transform set or not depending
on the negotiation. This is important because in certain vvc1/vvi1 streams we
may have correct codec_data but faulty parameter sets in the stream and
we would want to push the parameter sets from codec_data first.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8359>
implement serialization of codec_data containing VvcDecoderConfigurationRecord
as defined in ISO/IEC 14996-15.
The VPS/SPS/PPS NALs are added to the codec_data. APS NALs could be
optionally included as well but will be pushed in-band instead, because:
1. Logic is easier that way. We'd have to filter out for PREFIX_APS only
(SUFFIX_APS aren't allowed in codec_data).
2. APS NALs can also be sent for every non-keyframe slice, and often are, so just pushing
them in-band makes more sense to have less to keep track and avoid possible
duplicates.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8359>
If collecting the backchannel stream after the stream has begun
preparing, make sure to join it to the RTSP media bin, as is
done for dynamic payloaders in the pad-added handler. Add a
new internal stream creation method for it, that could be
publically exposed later if it proves useful.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8378>
When prerolling / blocking an RTSP media, don't consider receiver
streams like onvif backchannel in the 'is everything blocked' check,
as those streams won't receive data until after the RTSP stream
is running.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8378>
When decoupling send/receive loops in rtsp-media using appsink/appsrc,
put the appsink in the bin before linking it, as this code path
had that wrong.
For both sender and receiver paths, if the pipeline already started
also add the other appsrc/appsink of the pair to the pipeline
immediately instead of putting it in the pending elements list,
as they won't get added later.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8378>
The example was switched to use autovideosink, which broke
current position calculation based on the last video frame.
Add code to retrieve the actual video sink from within autovideosink
to make it work again.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8378>
Suppose you're trying to debug why this pipeline doesn't work:
```
$ GST_DEBUG=GST_PIPELINE:DEBUG gst-launch-1.0 \
videotestsrc num-buffers=10 ! x264enc name=enc ! mux.sink_0 \
mpegtsmux name=mux ! fakesink
```
You will encounter this line in the logs:
> gst_parse_perform_link: linking some pad of GstX264Enc named enc to
> pad mux of GstMpegTsMux named mux (0/1) with caps "(NULL)"
It would seem that the element name is being read as a pad name as well,
and that made me wonder if the parsing was not working. However, it was
just a bug in the code printing that log. This patch fixes that bug.
Note that it is possible to specify more than one pad name for each side
of the link. For instance, the following is a valid pipeline that will
remux the video and audio of an MP4 file into MKV:
```
$ GST_DEBUG=GST_PIPELINE:DEBUG gst-launch \
filesrc location=input.mp4 ! qtdemux name=demux \
multiqueue name=mq \
matroskamux name=mux ! filesink location=output.mkv \
demux.video_0,audio_0 ! mq.sink_0,sink_1 \
mq.src_0,src_1 ! mux.video_0,audio_0
```
The new logging accomodates this by using a new utility function to join
strings of pad name lists instead of `PRETTY_PAD_NAME_FMT` (which only
supports one pad name). For example:
> linking pads {video_0, audio_0} of GstQTDemux named demux to pads
> {sink_0, sink_1} of GstMultiQueue named mq with caps "(NULL)"
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8415>
"undefined reference to `GST_TRACER_PAD_SEND_EVENT_PRE'
undefined reference to `GST_TRACER_PAD_SEND_EVENT_POST'"
errors are generated when trying to build GStreamer with
the following build configuration:
meson setup -Dgstreamer:tracer_hooks=false build
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8419>
