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>
Similar to qtdemux.
Tested against other Gst elements and MPV. Note that the later
apparently does not show correct results for flipped values.
In particular the Yaw value seems to get ignored by many clients.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8319>
Similar to qtmux, but for mkv and webm containers.
Tested against other Gst elements and MPV. Note that the later
apparently does not show correct results for flipped values.
In particular the Yaw value seems to get ignored by many clients.
Can be tested with:
```
gst-launch-1.0 \
videotestsrc num-buffers=90 ! \
taginject tags="image-orientation=rotate-270" ! \
capsfilter caps=video/x-raw,width=640,height=480,max-framerate=30/1 ! \
videoconvert ! \
queue ! \
vp8enc ! \
queue ! \
webmmux ! \
filesink location=./test.webm
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8319>
There's a different way to list the files between the former pre-commit
hook (which ran gst-indent directly on the output of git diff-index)
and the former CI check job (which ran gst-indent-all wholesale).
It can be easily addressed by detecting CI_PROJECT_NAME at listing time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8409>
Sometimes the seek to the end of file to determine the duration would trigger a
reset of the source pads, that would confuse the decoder downstream and trigger
an error. So the proposed fix is to not reset pads when the segment event being
processed is the consequence of a seek performed to determine the duration.
Fixes#4212
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/937>
