Got EOS from element "pipeline0" -> help with sometimes pads

[Graham Leggett]

Hi all,

I have the following streaming pipeline which runs for a few seconds, and then without being asked to, the pipeline gracefully shuts down as below.

For obvious reasons this is fatal for streaming - this needs to stream forever, and not shut down.

I am trying to understand the cause of this behaviour, and am struggling. As a guess, would “sometimes” pads be potentially involved? The tsdemux exposes sometimes pads, which delays the linking of the queue element. Am I right in guessing that if for some reason tsdemux decided to remove a sometimes pad for whatever reason (errors in the stream, who knows), this would trigger the rest of the stream and therefore the whole pipeline to shut down?

If so, what could I do to prevent the shutdown? Is there an element that will relink a sometimes pad to an always pad on an unreliable stream if the sometimes pad goes away and comes back?

pi@towerofpi9:~$ gst-launch-1.0 udpsrc multicast-iface=eth0 uri=udp://239.106.0.0:1234 "caps=application/x-rtp,media=(string)video,clock-rate=(int)90000" ! rtpbin ! rtpmp2tdepay ! progressreport update-freq=5 ! tsparse ! tsdemux emit-stats=true name=demux ! queue leaky=downstream max-size-time=5000000000 ! h264parse ! omxh264dec ! videoscale ! video/x-raw,width=960,height=540 ! fakesink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
progressreport0 (00:00:05): 4 seconds
progressreport0 (00:00:10): 9 seconds
progressreport0 (00:00:15): 14 seconds
Got EOS from element "pipeline0".
Execution ended after 0:00:19.144782824
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline …

Regards,
Graham
—


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

[Sebastian Dröge-3]

On Mon, 2016-10-24 at 22:44 +0200, Graham Leggett wrote:

> Hi all,
>
> I have the following streaming pipeline which runs for a few seconds,
> and then without being asked to, the pipeline gracefully shuts down
> as below.
>
> For obvious reasons this is fatal for streaming - this needs to
> stream forever, and not shut down.
>
> I am trying to understand the cause of this behaviour, and am
> struggling. As a guess, would “sometimes” pads be potentially
> involved? The tsdemux exposes sometimes pads, which delays the
> linking of the queue element. Am I right in guessing that if for some
> reason tsdemux decided to remove a sometimes pad for whatever reason
> (errors in the stream, who knows), this would trigger the rest of the
> stream and therefore the whole pipeline to shut down?

The stream could've changed, in which case you would have to link
dynamically new pads to the new pads of tsdemux (you can't do that with
gst-launch), or it might've encountered an error.

If you use playbin, it would handle that internally.

> If so, what could I do to prevent the shutdown? Is there an element
> that will relink a sometimes pad to an always pad on an unreliable
> stream if the sometimes pad goes away and comes back?

No but that can be implemented with some code

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel