tcpclient failing to detect EOF/EOS?

[Tim-Philipp Müller]

On Mon, 2013-08-26 at 14:46 +0200, Peter Maersk-Moller wrote:

Hi Peter,


>         It is not besides the point, because without the pipeline
>         prerolling EOS
>         propagation will not work.
> 
> 
> Right. So what you are saying is this: 

Note that I'm just drive-by commenting. What's right in your exact
situation depends a bit on circumstances. Also, keep in mind that
gst-launch is merely a debugging tool and has some limitations that an
app does not necessarily have (where you can plug things dynamically
later).


> While a pipeline is prerolling, it can NOT propagate EOS

This is all a matter of definition. I don't think this statement is
correct as it is. Prerolling is a mechanism, not a state really. EOS
will be passed through the pipeline just like data. It's perfectly
possible to "propagate EOS" whil the pipeline is prerolling. e.g.:

  gst-launch-1.0 fakesrc num-buffers=0 ! queue ! fakesink

works just fine.

Note that EOS is only rendered (takes effect) (by the sinks) when the
pipeline goes to PLAYING state. This means the pipeline needs to preroll
and go into PAUSED state first if you want proper EOS propagation.


>  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.

It pushes an EOS event through the pipeline, which goes through all
elements on the way to a sink (hopefully). The source doesn't know
anything about the sink directly. So yes.


> 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?

Uhm, I don't see how that follows. Yes, I think it's a problem. The
pipeline should never just sit there. It should be fixed, and can be
fixed.

For example, the demuxer could/should maybe post an error message on the
bus if it receives an EOS event but hasn't created any source pads yet.

It could also post an EOS message, but that's conceptually hairy, not
sure it's right. Maybe Wim has an opinion on this.

> 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.

It should terminate somehow, never just sit there.

Cheers
 -Tim

> 
>         > Apparently tcpclientsrc fails to make the pipeline terminate
>         upon
>         > EOS/EOF if it is in its prerolling state.
>         
>         
>         It is not the source that terminates the pipeline on EOS. It
>         pushes an
>         EOS even into the pipeline, which then needs to filter through
>         to sinks,
>         which then post EOS messages on the bus, which the pipeline
>         then
>         aggregates.
> 
> 
> True, but problem still apply.
>  
> 
>         
>         >  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.
>         
>         
>         Does the sink not post an error messages if its connection is
>         disconnected by the peer? Shouldn't it?
> 
> 
> 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.
> 
> 
> Best regards
> 
> Peter Maersk-Moller
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel