Unknown Event stops clients

[Peter Maersk-Moller]

Hi.

I am receiving on a server a RTP TS stream over UDP and making it available
to through tcpserversink to clients running on RaspberryPi. However after a
few seconds (or sometimes more) the clients on the rasps and the PC stops
playing.

Trying to enabling debug on the server, I see the INFO below and the
clients stops shortly after the event at 0:00:35.410329285  listed below

0:00:29.452785777 10181      0x13ac5e0 INFO               h264parse
gsth264parse.c:1271:gst_h264_parse_update_src_caps:<h264parse0> PAR 1/1
0:00:31.454396713 10181      0x13ac5e0 INFO               baseparse
gstbaseparse.c:3635:gst_base_parse_set_latency:<h264parse0> min/max latency
0:00:00.041666666, 0:00:00.041666666
0:00:31.454471237 10181      0x13ac5e0 INFO               h264parse
gsth264parse.c:1271:gst_h264_parse_update_src_caps:<h264parse0> PAR 1/1
0:00:33.452275861 10181      0x13ac5e0 INFO               baseparse
gstbaseparse.c:3635:gst_base_parse_set_latency:<h264parse0> min/max latency
0:00:00.041666666, 0:00:00.041666666
0:00:33.452352061 10181      0x13ac5e0 INFO               h264parse
gsth264parse.c:1271:gst_h264_parse_update_src_caps:<h264parse0> PAR 1/1
0:00:35.410329285 10181      0x13ac720 INFO               GST_EVENT
gstevent.c:759:gst_event_new_segment: creating segment event time segment
start=0:00:35.463807188, offset=0:00:00.000000000, stop=99:99:99.999999999,
rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.000000000,
base=0:00:00.000000000, position 0:00:35.463807188, duration
99:99:99.999999999
0:00:35.452353923 10181      0x13ac5e0 INFO               baseparse
gstbaseparse.c:3635:gst_base_parse_set_latency:<h264parse0> min/max latency
0:00:00.041666666, 0:00:00.041666666
0:00:35.452397436 10181      0x13ac5e0 INFO               h264parse
gsth264parse.c:1271:gst_h264_parse_update_src_caps:<h264parse0> PAR 1/1
0:00:37.493955695 10181      0x13ac5e0 INFO               baseparse
gstbaseparse.c:3635:gst_base_parse_set_latency:<h264parse0> min/max latency
0:00:00.041666666, 0:00:00.041666666
0:00:37.494024282 10181      0x13ac5e0 INFO               h264parse
gsth264parse.c:1271:gst_h264_parse_update_src_caps:<h264parse0> PAR 1/1
0:00:39.452076236 10181      0x13ac5e0 INFO               baseparse
gstbaseparse.c:3635:gst_base_parse_set_latency:<h264parse0> min/max latency
0:00:00.041666666, 0:00:00.041666666

What kind of event is this and is there a way to mitigate the effects of
the event?

The pipeline I use on the server is this:


caps='application/x-rtp,media=video,clock-rate=90000,encoding-name=MP2T,payload=96'
        QUEUE0='queue max-size-buffers=0 max-size-time=0 max-size-bytes=0'

        /usr/local/bin/gst-launch-1.0 -v --gst-debug=*:4
--gst-debug-no-color \
                udpsrc port=8000 do-timestamp=true !\
                $caps   !\
                rtpmp2tdepay !\
                $QUEUE0 !\
                tsparse !\
                tsdemux name=demux !\
                $QUEUE0 !\
                h264parse !\
                $QUEUE0 !\
                mux. demux. !\
                $QUEUE0 !\
                mpegaudioparse !\
                $QUEUE0 !\
                matroskamux name=mux streamable=true !\
                queue !\
                tcpserversink host=0.0.0.0 port=$serverport sync-method=2
recover-policy=keyframe sync=true

The pipeline used on the RaspPis is this:
        gst-launch-1.0 -v -e \
                tcpclientsrc host=$server port=$port    !\
                queue leaky=2                           !\
                decodebin name=decoder                  !\
                queue ! autovideosink

Similar pipeline is used on the PC. Connecting to the server port reveals,
that the server has stopped serving a stream.

I can then stop the pipeline on the server, start it again and start the
clients and make them run for a few seconds or up to severals minutes again
etc.

Is there a way to avoid this?

The TS stream is a H264+MP3 stream TS-muxed, chooped to 1316 bytes and
added RTP header and sent over UDP, in this case on local network, but
later for transmission over a more unpredictable network.

Regards
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140630/2cb86f6d/attachment.html>