stop/restart parts of pipeline

[Marc]

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

[Thornton, Keith]

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:[hidden email]] Im Auftrag von Marc
Gesendet: Freitag, 21. Juli 2017 10:41
An: [hidden email]
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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

An alternative solution is to use intervideosrc/sink. This will let you
multi-plex the camera to multiple independent pipelines.

    /* The "server" */
    v4l2src ! intervideosink channel=cam1

    /* The "clients" */
    intervideosrc channel=cam1 ! kmssink
    intervideosrc channel=cam1 ! ...

regards,
Nicolas

Le vendredi 21 juillet 2017 à 09:14 +0000, Thornton, Keith a écrit :

> 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:[hidden email]
> p.org] Im Auftrag von Marc
> Gesendet: Freitag, 21. Juli 2017 10:41
> An: [hidden email]
> 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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

[Marc]

Thanks for your suggestion. But when the eos arrives at the sink pads of the sink elements, it is not yet processed by those sink elements?! So when I immediately unlink and delete the branches, how is it guaranteed that the recorded files are closed properly?!

Marc

[Marc]

Hi Nicolas,
what do you think of this http://gstreamer-devel.966125.n4.nabble.com/Dynamically-updating-filesink-location-at-run-time-on-the-fly-td4660569.html? Can this be applied here? Is the eos processed by all elements when the callback is executed?

Marc