<html><head></head><body><div style="color:#000; background-color:#fff; font-family:lucida console, sans-serif;font-size:13px"><div id="yui_3_16_0_ym19_1_1480716538353_5093" dir="ltr"><span id="yui_3_16_0_ym19_1_1480716538353_5162">I am back on this issue. As a refresher, I am seeing long pauses every 10 seconds when playing a rtsp stream from a wifi camera.</span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480716538353_6365"><span id="yui_3_16_0_ym19_1_1480716538353_5162"><br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480716538353_6403"><span id="yui_3_16_0_ym19_1_1480716538353_6368">The receiver pipeline is:</span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480716538353_6404"><span id="yui_3_16_0_ym19_1_1480716538353_6368"></span><br><span id="yui_3_16_0_ym19_1_1480716538353_6369">gst-launch-1.0.exe -v -m </span>rtspsrc location=rtsp://192.x.x.x/AmbaStreamTest latency=30 ! decodebin ! timeoverlay ! autovideosink</div><div dir="ltr" id="yui_3_16_0_ym19_1_1480716538353_5143"><span><br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480716538353_5144"><span id="yui_3_16_0_ym19_1_1480716538353_5548">It was mentioned that the server might be sending data as fast as it can and not in real time.</span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480716538353_6024"><span id="yui_3_16_0_ym19_1_1480716538353_6023">Would that be possible when the server is a live camera ?</span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480716538353_6406"><span id="yui_3_16_0_ym19_1_1480716538353_6023"><br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480716538353_6734"><span id="yui_3_16_0_ym19_1_1480716538353_6023">It was also suggested to try a non slave buffer-mode. I tried all buffer modes:</span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480716538353_6756"><span id="yui_3_16_0_ym19_1_1480716538353_6023">- "none" : video turns into a slide show and the video sink emits warnings about "a lot of buffers are being dropped"</span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480716538353_6905"><span id="yui_3_16_0_ym19_1_1480716538353_6023">- "synced" and "buffer" : both have the pause issue.<br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480716538353_5244"><span><br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480716538353_6026"><span id="yui_3_16_0_ym19_1_1480716538353_6025">I have used wireshark to capture the RTP traffic for a period of 20 seconds (so it includes at least one pause).<br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480716538353_6997"><span id="yui_3_16_0_ym19_1_1480716538353_6025"><br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480716538353_6996"><span id="yui_3_16_0_ym19_1_1480716538353_6025">What I noticed is that the pipeline sends a Receiver Report every 10 seconds.</span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480716538353_7789"><span id="yui_3_16_0_ym19_1_1480716538353_7814"> Around the </span><span id="yui_3_16_0_ym19_1_1480716538353_6025"><span id="yui_3_16_0_ym19_1_1480716538353_7815">Receiver Report</span> it seems that the RTP stream is stalling/pausing for a few secs.</span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480716538353_7474"><span id="yui_3_16_0_ym19_1_1480716538353_6025">Here is a typical sequence around the Reveiver Report message:</span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480716538353_7473"><span id="yui_3_16_0_ym19_1_1480716538353_6025"><br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480716538353_7407"><span id="yui_3_16_0_ym19_1_1480716538353_6025">No. Time Source Destination Protocol Length Info<br id="yui_3_16_0_ym19_1_1480716538353_7429">61777 609.874675 192.168.42.1 192.168.42.3 RTP 68 PT=DynamicRTP-Type-96, SSRC=0xF8512ADB, Seq=53358, Time=860883236<br id="yui_3_16_0_ym19_1_1480716538353_7430">61778 609.874676 192.168.42.1 192.168.42.3 RTP 240 PT=DynamicRTP-Type-96, SSRC=0xF8512ADB, Seq=53359, Time=860883236, Mark<br id="yui_3_16_0_ym19_1_1480716538353_7431">61779 609.907745 192.168.42.1 192.168.42.3 RTP 68 PT=DynamicRTP-Type-96, SSRC=0xF8512ADB, Seq=53360, Time=860886239<br id="yui_3_16_0_ym19_1_1480716538353_7432">61780 609.907746 192.168.42.1 192.168.42.3 RTP 300 PT=DynamicRTP-Type-96, SSRC=0xF8512ADB, Seq=53361, Time=860886239, Mark<br id="yui_3_16_0_ym19_1_1480716538353_7433">61781 611.344276 192.168.42.3 192.168.42.1 RTCP 126 Receiver Report Source description <br id="yui_3_16_0_ym19_1_1480716538353_7434">61782 612.994309 192.168.42.1 192.168.42.3 RTP 68 PT=DynamicRTP-Type-96, SSRC=0xF8512ADB, Seq=53362, Time=860889242<br id="yui_3_16_0_ym19_1_1480716538353_7435">61783 612.994311 192.168.42.1 192.168.42.3 RTP 435 PT=DynamicRTP-Type-96, SSRC=0xF8512ADB, Seq=53363, Time=860889242, Mark<br id="yui_3_16_0_ym19_1_1480716538353_7436">61784 612.994311 192.168.42.1 192.168.42.3 RTP 68 PT=DynamicRTP-Type-96, SSRC=0xF8512ADB, Seq=53364, Time=860892245<br id="yui_3_16_0_ym19_1_1480716538353_7437">61785 612.994312 192.168.42.1 192.168.42.3 RTP 386 PT=DynamicRTP-Type-96, SSRC=0xF8512ADB, Seq=53365, Time=860892245, Mark<br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480716538353_7313"><span id="yui_3_16_0_ym19_1_1480716538353_6025"><br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480716538353_7405"><span id="yui_3_16_0_ym19_1_1480716538353_6025">Not sure it means anything...<br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480716538353_6028"><span></span></div> <div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: lucida console, sans-serif; font-size: 13px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"><font face="Arial" size="2"> Le Samedi 12 novembre 2016 10h11, Sebastian Dröge <sebastian@centricular.com> a écrit :<br></font></div> <blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; margin-top: 5px; padding-left: 5px;"> <br><br> <div class="y_msg_container">On Wed, 2016-11-09 at 22:14 +0000, philippe renon wrote:<br clear="none"><br clear="none">> element autovideosink1-actual-sink-d3dvideo sent qos event: live: 1;<br clear="none">> running time: 30719164049; stream time: 26558070697; timestamp:<br clear="none">> 30719164049; duration: 33366666 jitter: 3029708354; proportion:<br clear="none">> 0.15581; quality: 1000000; format: ; processed: 609; dropped: 2;<br clear="none">> <br clear="none">> The rtpjitterbuffer skew is initially around 8 as expected but then<br clear="none">> starts to increase to reach values in the 200.<br clear="none"><br clear="none">This suggests that the server is sending data not in real-time but as<br clear="none">fast as it can. Something definitely seems to be odd with the stream<br clear="none">here, but we should also be able to handle that better.<br clear="none"><br clear="none">> I am attaching a dot file of the pipeline at the time a qos event was<br clear="none">> sent.<br clear="none">> <br clear="none">> Is it possible to disable the rtpjitterbuffer used in the rtspsrc<br clear="none">> bin. If if not, is it possible to create a rtspsrc from its<br clear="none">> individual elements with gst-launch ?<br clear="none"><br clear="none">No, rtspsrc is more than the combination of the elements it is<br clear="none">containing. Disabling the rtpjitterbuffer is not possible, but you can<br clear="none">specify a different buffer-mode on it. The non-slave ones probably work<br clear="none">better in your case, but come with other problems.<br clear="none"><br clear="none">> Would a wireshark log help ?<br clear="none"><br clear="none">If someone has time to look into it and come up with a way to handle<br clear="none">the stream, sure.<div class="yqt0855866407" id="yqtfd41791"><br clear="none"><br clear="none">-- <br clear="none">Sebastian Dröge, Centricular Ltd · <a shape="rect" href="http://www.centricular.com/" target="_blank">http://www.centricular.com</a></div><br><br></div> </blockquote> </div> </div> </div></div></body></html>