<div dir="ltr"><div>Hi Timm-Phillipp<br><br></div>See comments in-line.<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 25, 2013 at 2:14 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">On Sat, 2013-08-24 at 23:59 +0200, Peter Maersk-Moller wrote:<br>
Hi,<br><div class="im">
> Yes, the prerolling receiver needs a queue that in this case will make<br>
> the pipeline change to playing after it has prerolled. However, that<br>
> is mostly besides the point.<br>
</div>It is not besides the point, because without the pipeline prerolling EOS<br>
propagation will not work.<br></blockquote><div><br></div><div>Right. So what you are saying is this: While a pipeline is prerolling, it can NOT propagate EOS and later on you write that if a source detects EOF, it signals to the sink of the pipeline and then the sink may later signal EOS, when it enters Playing state.<br>
<br></div><div>Then I conclude this: If GStreamer has no other way to handle EOF for input while prerolling, then GStreamer pipelines has a race condition and as such it can be impossible to determine the exact outcome of a particular scenario. Now I will not race to conclusion and race condtions can be many things and even okay if handled properly, but here the pipeline ends up doing nothing just sitting there and that somehow sounds pretty bad to me. Don't you think that is a problem?<br>
<br>Somehow the sink needs to detect if it will NOT receive more data from upstream, and if the pipeline is still prerolled, the sink should send the EOS upstream. At least that that is the only way I know a pipeline will terminate.<br>
<br></div><div>Am I wrong ?<br></div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Apparently tcpclientsrc fails to make the pipeline terminate upon<br>
> EOS/EOF if it is in its prerolling state.<br>
<br>
</div>It is not the source that terminates the pipeline on EOS. It pushes an<br>
EOS even into the pipeline, which then needs to filter through to sinks,<br>
which then post EOS messages on the bus, which the pipeline then<br>
aggregates.<br></blockquote><div><br></div><div>True, but problem still apply.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div class="im">
>  If the tcpserversink disconnects or the connection is disconnected<br>
> for any other reason while the receiver pipeline with tcpclientsrc is<br>
> prerolling, the pipeline may never enter playing state and<br>
> subsequently the pipeline is not terminated even though its source had<br>
> its conection terminated. or at least that is what I seem to<br>
> experience.<br>
<br>
</div>Does the sink not post an error messages if its connection is<br>
disconnected by the peer? Shouldn't it?<br></blockquote><div><br></div><div>Not sure if it does, but the sink at the end of the pipeline should somehow detects when it will never leave the prerolling state and terminate. Otherwise you have the race condition. And that is often pretty bad.<br>
<br></div><div>Best regards<br></div><div>Peter Maersk-Moller<br></div></div></div></div></div></div>