Dynamically changing the pipeline

[Alexander Binzberger]

Hi guys,
I am trying to change the pipeline dynamically but do not get it working. I also did not get splitmuxsrc working but that is a different story.

The general idea is recording a rtp live stream to disk and split it into files of some size or time. For this part splitmuxsink seems to work well.
gst-launch-1.0 -e rtpbin udpsrc caps="application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264" address=232.0.0.1 port=5000 ! rtph264depay ! h264parse ! splitmuxsink location=~/video%02d.mp4 max-size-time=90000000000 max-size-bytes=100000000
The next step is playing it back (a bit like a DVR) as a playlist or chunks/files (as rtp again). This is where i struggle. My pipeline looks basically like this:
gst-launch-1.0 rtpbin name=rtpbin
    filesrc location=/home/user/video00.mp4 ! qtdemux ! h264parse ! rtph264pay ! capsfilter 'application/x-rtp,ssrc=(uint)1356955624' ! rtpbin.send_rtp_sink_0
                  rtpbin.send_rtp_src_0 ! udpsink port=5000                           
                  rtpbin.send_rtcp_src_0 ! udpsink port=5001 sync=false async=false   
                  udpsrc port=5005 ! rtpbin.recv_rtcp_sink_0

(I was expecting splitmuxsrc to work in the reverse way but it did not somehow and the limitation to the pattern is not exactly what I need anyway.)
Then I was trying it with concat what works well but I want to add new files to the playlist dynamically and seek between them. So I was writing some code and trying to dynamically change the pipeline (like in the documentation page with the same name).
So first I tried to find a signal or event at the filesrc which tells me when I need to read the next element. I was expecting EOS for example but did not get it there.
Then I found out the EOS seems to get created by the demuxer and I tried to probe it there. In the blocking probe I tried to change the location of the filesrc but it complains then.
So I tried to change the state to null for the filesrc, change the location and set the state back to playing. Then I got errors about demux.sink was in push mode - which I do not understand. I also got errors telling me I am in the wrong thread for the change.
How can it be the wrong thread for me when the example does it in the same way and place?
However just to be sure I also tried two different filesrc elements and creating a new one but I end up with the same thing all the time.
I also tried a idle callback on the filesrc which did not kick in and a g_idle_add was also not working out for me.

What is the correct or best way to achieve this? What is my mistake here?

Thanks
Alex


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tim Müller]

On Wed, 2018-07-11 at 16:06 +0200, Alexander Binzberger wrote:

Hi Alexander,

Lots of stuff to process in here.

In general, you can't just shut down filesrc and restart it with a new
file and expect the demuxer downstream to just work on the new file,
that's not really how things work from a data processing perspective in
GStreamer. You need to shut down or replace both filesrc ! demuxer.

If you want to support seeking across chunks then you need to use
splitfilesrc. The best approach might be to add some new API to
splitfilesrc to support specifying or filtering the files to load, and
to add new files on the fly.

The state change warning you got may have been because you were trying
to shut down an element or the pipeline from within its own a streaming
thread (e.g. pad probe callback or so). Which is not allowed. Without
seeing the code I can only guess though.

Cheers
 -Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.com

Join us at the GStreamer Conference! 25-26 October 2018 in Edinburgh,
Scotland
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel