tcpclient failing to detect EOF/EOS?

[Peter Maersk-Moller]

Hi Tim

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.
What do you think?

Best regards
Peter


On Sat, Aug 24, 2013 at 5:25 PM, Tim-Philipp Müller <t.i.m at zen.co.uk> wrote:

> On Sat, 2013-08-24 at 16:19 +0200, Peter Maersk-Moller wrote:
>
> > Is it a bug or a feature, that tcpclientsrc seems to fail to detect
> > EOF/EOS and terminate a pipeline if its pipeline is PREROLLED and not
> > yet PLAYING?
> >
> >
> > You can verified it by executing the following two pipeline in the
> > listed order and then terminate the first pipeline.
> >
> > Sender Pipeline:
> > gst-launch -v videotestsrc is-live=true ! x264enc ! queue ! mux.
> > audiotestsrc is-live=true ! faac ! mpegtsmux name=mux ! queue !
> > tcpserversink port=5010
> >
> > Receiver Pipeline
> > gst-launch-1.0 -v tcpclientsrc port=5010 ! tsdemux name=demux !
> > 'audio/mpeg' ! fakesink demux. ! 'video/x-h264' ! fakesink
> >
> >
> > Start sender, then receiver and see that receiver only prerolls and
> > does not enter state playing (the pipeline needs queues). Then
> > terminate the sender and see that the receiver stays prerolled.
> >
> >
> > The behaviour makes it difficult to construct a pipeline with
> > tcpclientsrc without the risk of a race condition for the system.
> >
> >
> > Shouldn't tcpclientsrc detect the sender has disconnected and
> > subsequently shutdown the pipeline?
>
> The problem in this case might be a general prerolling problem, namely
> that you need a queue after each demux. ! ...
>
> Cheers
>  -Tim
>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130824/305ad916/attachment.html>