<div dir="ltr"><div><div><div><div>Hi Tim<br><br></div>Yes, the prerolling receiver needs a queue that in this case will make the pipeline change to playing after it has prerolled. However, that is mostly besides the point. Apparently tcpclientsrc fails to make the pipeline terminate upon EOS/EOF if it is in its prerolling state. If the tcpserversink disconnects or the connection is disconnected for any other reason while the receiver pipeline with tcpclientsrc is prerolling, the pipeline may never enter playing state and subsequently the pipeline is not terminated even though its source had its conection terminated. or at least that is what I seem to experience. If that is the case, we have a race condition that potentially can render a system inoperable. Technically you could have another process that somehow magically determines the receiver pipeline is hanging and then decide to kill the receiver process, but that is quite cumbersome as a workaround.<br>
</div>What do you think?<br><br></div>Best regards<br></div>Peter<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Aug 24, 2013 at 5:25 PM, Tim-Philipp Müller <span dir="ltr"><<a href="mailto:t.i.m@zen.co.uk" target="_blank">t.i.m@zen.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Sat, 2013-08-24 at 16:19 +0200, Peter Maersk-Moller wrote:<br>
<br>
> Is it a bug or a feature, that tcpclientsrc seems to fail to detect<br>
> EOF/EOS and terminate a pipeline if its pipeline is PREROLLED and not<br>
> yet PLAYING?<br>
><br>
><br>
> You can verified it by executing the following two pipeline in the<br>
> listed order and then terminate the first pipeline.<br>
><br>
> Sender Pipeline:<br>
> gst-launch -v videotestsrc is-live=true ! x264enc ! queue ! mux.<br>
> audiotestsrc is-live=true ! faac ! mpegtsmux name=mux ! queue !<br>
> tcpserversink port=5010<br>
><br>
> Receiver Pipeline<br>
> gst-launch-1.0 -v tcpclientsrc port=5010 ! tsdemux name=demux !<br>
> 'audio/mpeg' ! fakesink demux. ! 'video/x-h264' ! fakesink<br>
><br>
><br>
> Start sender, then receiver and see that receiver only prerolls and<br>
> does not enter state playing (the pipeline needs queues). Then<br>
> terminate the sender and see that the receiver stays prerolled.<br>
><br>
><br>
> The behaviour makes it difficult to construct a pipeline with<br>
> tcpclientsrc without the risk of a race condition for the system.<br>
><br>
><br>
> Shouldn't tcpclientsrc detect the sender has disconnected and<br>
> subsequently shutdown the pipeline?<br>
<br>
</div></div>The problem in this case might be a general prerolling problem, namely<br>
that you need a queue after each demux. ! ...<br>
<br>
Cheers<br>
 -Tim<br>
<br>
<br>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote></div><br></div>