<div dir="ltr"><div><div>Hi.<br><br></div>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.<br>
<br></div>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<br><div><br>0:00:29.452785777 10181      0x13ac5e0 INFO               h264parse gsth264parse.c:1271:gst_h264_parse_update_src_caps:<h264parse0> PAR 1/1<br>
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<br>0:00:31.454471237 10181      0x13ac5e0 INFO               h264parse gsth264parse.c:1271:gst_h264_parse_update_src_caps:<h264parse0> PAR 1/1<br>
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<br>0:00:33.452352061 10181      0x13ac5e0 INFO               h264parse gsth264parse.c:1271:gst_h264_parse_update_src_caps:<h264parse0> PAR 1/1<br>
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<br>
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<br>0:00:35.452397436 10181      0x13ac5e0 INFO               h264parse gsth264parse.c:1271:gst_h264_parse_update_src_caps:<h264parse0> PAR 1/1<br>
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<br>0:00:37.494024282 10181      0x13ac5e0 INFO               h264parse gsth264parse.c:1271:gst_h264_parse_update_src_caps:<h264parse0> PAR 1/1<br>
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<br><br></div><div>What kind of event is this and is there a way to mitigate the effects of the event?<br>
<br></div><div>The pipeline I use on the server is this:<br><br>        caps='application/x-rtp,media=video,clock-rate=90000,encoding-name=MP2T,payload=96'<br>        QUEUE0='queue max-size-buffers=0 max-size-time=0 max-size-bytes=0'<br>
<br>        /usr/local/bin/gst-launch-1.0 -v --gst-debug=*:4 --gst-debug-no-color \<br>                udpsrc port=8000 do-timestamp=true !\<br>                $caps   !\<br>                rtpmp2tdepay !\<br>                $QUEUE0 !\<br>
                tsparse !\<br>                tsdemux name=demux !\<br>                $QUEUE0 !\<br>                h264parse !\<br>                $QUEUE0 !\<br>                mux. demux. !\<br>                $QUEUE0 !\<br>
                mpegaudioparse !\<br>                $QUEUE0 !\<br>                matroskamux name=mux streamable=true !\<br>                queue !\<br>                tcpserversink host=0.0.0.0 port=$serverport sync-method=2 recover-policy=keyframe sync=true<br>
<br></div><div>The pipeline used on the RaspPis is this:<br>        gst-launch-1.0 -v -e \<br>                tcpclientsrc host=$server port=$port    !\<br>                queue leaky=2                           !\<br>                decodebin name=decoder                  !\      <br>
                queue ! autovideosink<br><br></div><div>Similar pipeline is used on the PC. Connecting to the server port reveals, that the server has stopped serving a stream.<br><br></div><div>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.<br>
<br></div><div>Is there a way to avoid this?<br><br></div><div>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.<br>
<br></div><div>Regards<br></div><div>Peter<br></div><div><br><br></div></div>