AW: stop/restart parts of pipeline

Fri Jul 21 09:14:30 UTC 2017

Hi,
you could set a pad probe on the sink pads of the two sink elements and wait for the EOS event to arrive at these pad probes. My experience has been that I prefer then to unlink remove and delete the elements belonging to the branch and when they are needed the next time I re-build the branch. This may be just a personal preference.

-----Ursprüngliche Nachricht-----
Von: gstreamer-devel [mailto:gstreamer-devel-bounces at lists.freedesktop.org] Im Auftrag von Marc
Gesendet: Freitag, 21. Juli 2017 10:41
An: gstreamer-devel at lists.freedesktop.org
Betreff: stop/restart parts of pipeline

Hello,
I have the following pipeline which has 3 parallel branches. One branch for live view, one for network streaming and one for recording. The live view branch should always play. The other two branches should be stopped and restarted independently by user request.

v4l2src->tee->queue->kmssink

->queue->h264enc->queue->h264parse->tee->queue1->mpegtsmux->updsink

->queue2->mp4mux->filesink

Audio is additionally fed into the muxers which is not shown above. The question now is how can I stop and restart the streaming and recording branches? I thought of blocking the queue1/2 pads and sending eos downstream. But how do I know that eos has reached the udpsink/filesink?
What should be done afterwards (unlink, stop,...)? How can the branches be restarted? I read something that bins should be used for the two branches, because bins have eos finished callbacks? Is there another way to see that the udpsink/filesink have processed the eos?

Thanks for your help

Marc

--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/stop-restart-parts-of-pipeline-tp4683885.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel