tcpclient failing to detect EOF/EOS?

[Tim-Philipp Müller]

On Sat, 2013-08-24 at 23:59 +0200, Peter Maersk-Moller wrote:

Hi,

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

It is not besides the point, because without the pipeline prerolling EOS
propagation will not work.


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


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

Cheers
 -Tim

>  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
> 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel