<div dir="ltr"><div><div><div>I don't think this is related to the clock issue I was having.<br><br></div>I wasn't able to debug my issue as Sebastian suggested but I believe it was something to do with TSDemux. In summary the TS stream was obtained from a live BBC broadcast and would have contained timestamps from some synchronised source. The PC running GStreamer was not synchronised and was free to drift. I had an rtpbin that was correcting the timestamp skew of the rtp packets but once they hit TSDemux those rtp timestamps were discarded in favour of the timestamps obtained from within the TS stream itself. The skew between the TS stream and the local clock wasn't corrected and so the pipeline slowly drifted behind the input stream. The sync option on the UDP sink was doing its job.<br><br></div>The simple solution in that case was to synchronise the PC to a NTP time source.<br><br></div>I did experience exactly the same issue as you are seeing when I tried to create an artificial TS stream from a local file on the disk to test the my pipeline. Just as you are seeing it streamed the entire file as fast as possible. I didn't have time to look into it so I forgot about it.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 February 2016 at 12:36, Angel Martin <span dir="ltr"><<a href="mailto:amartin@vicomtech.org" target="_blank">amartin@vicomtech.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I have posted this behavior in another post but I think it is close related with that one:</div><div>"<span style="font-size:12.8px">The only thing that the </span><span style="font-size:12.8px;background-color:rgb(255,255,255)">sync</span><span style="font-size:12.8px">=false on the </span><span style="font-size:12.8px;background-color:rgb(255,255,255)">udpsink</span><span style="font-size:12.8px"> would do is that </span><span style="font-size:12.8px">packets are sent immediately when they're ready instead of waiting </span><span style="font-size:12.8px">until their time to be sent arrives. This would potentially cause e.g. </span><span style="font-size:12.8px">audio packets for time T+10s to be sent at the same time as the video </span><span style="font-size:12.8px">packets for time T (and that would be a problem!) but if that causes </span><span style="font-size:12.8px">synchronization</span><span style="font-size:12.8px"> problems then your receiver is also doing things wrong.</span>"</div><div><br></div><div><div style="font-size:12.8px">In Gstreamer 1.4.4 the <span>udpsink</span> plugin with <span>sync</span>=<span>true</span> works in <span>real</span>-time. It means to stream a 2 minutes video file it takes 2 minutes (like a live source)</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">In Gstreamer 1.7.1 (also in 1.6.0) the <span>udpsink</span> plugin with <span>sync</span>=<span>true</span> works similar to <span>sync</span>=false. It means to stream a 2 minutes video file it takes 5 seconds (like a on demand source)<br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I used the next pipelines in the different Gstreamer versions:</div><div style="font-size:12.8px"><br></div><div><div style="font-size:12.8px">1) Create a sample file</div><div style="font-size:12.8px">gst-launch-1.0 -e videotestsrc ! video/x-raw, framerate=10/1, width=320, height=240, format=I420 ! timeoverlay font-desc="sans bold 40" halignment=0 valignment=2 ! x264enc bitrate=200 key-int-max=10 ! h264parse config-interval=1 ! mpegtsmux ! filesink location=test.ts</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">2a) Stream the file</div><div style="font-size:12.8px">gst-launch-1.0 filesrc location=test.ts ! tsparse ! tsdemux ! h264parse ! mpegtsmux ! rndbuffersize min=1316 max=1316 !<span>udpsink</span> port=5014 host=127.0.0.1 <span>sync</span>=<span>true</span> enable-last-sample=false send-duplicates=false blocksize=1316</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">3a) Play the Stream</div><div><span style="font-size:12.8px">gst-launch-1.0 <span>udpsrc</span> uri=<span>udp</span>://</span><a href="http://127.0.0.1:5014" target="_blank">127.0.0.1:5014</a><span style="font-size:12.8px"> ! video/mpegts ! tsdemux name=demux ! video/x-h264 ! queue ! decodebin ! autovideosink</span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><span style="font-size:12.8px">I have also tried with RTP packet encapsulation (the way you are discussing), but the problem persists:</span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div><div style="font-size:12.8px"><span style="font-size:12.8px">2b) </span><span style="font-size:12.8px">Stream the file RTP</span></div><div style="font-size:12.8px"><span style="font-size:12.8px">gst-launch-1.0 -e filesrc location=test.ts ! tsparse ! tsdemux ! h264parse ! mpegtsmux ! rndbuffersize min=1316 max=1316 ! rtpmp2tpay pt=96 ! udpsink port=5014 host=127.0.0.1 sync=true enable-last-sample=false send-duplicates=false blocksize=1316</span><br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">3b)<span style="font-size:12.8px"> </span><span style="font-size:12.8px">Play the Stream RTP</span></div><div><span style="font-size:12.8px">gst-launch-1.0 udpsrc uri=udp:/</span>/<a href="http://127.0.0.1:5014" target="_blank">127.0.0.1:5014</a><span style="font-size:12.8px"> caps="application/x-rtp, media=video, clock-rate=90000, encoding-name=MP2T-ES, payload=96" ! rtpmp2tdepay ! tsdemux ! video/x-h264 ! queue ! decodebin ! autovideosink</span></div></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><span style="font-size:12.8px">Best,</span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><span style="font-size:12.8px">Angel</span></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 26 December 2015 at 11:34, Sebastian Dröge <span dir="ltr"><<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Do, 2015-12-24 at 10:19 +0000, David Jaggard wrote:<br>
> The hardware in this case will only stream MPEG-TS. I'm wondering if<br>
> using a pipeline like udpsrc -> tsdemux -> h264parse -> rtph264pay -><br>
> udpsink [sync = false] (and similar for audio) would be a valid way<br>
> to convert it to rtp without affecting the timestamps (as there is no<br>
> jitter buffer and no synchronization at the sink) and I could then<br>
> pipe these streams into the transcoder for testing. Do you think this<br>
> would be valid?<br>
<br>
</span>That won't work as your stream is not plain MPEG-TS but MPEG-TS over<br>
RTP AFAIU. You at least need the depayloader before the tsdemux.<br>
<br>
This would work then but wouldn't account for packet reordering and<br>
packet loss, and you will likely get worse results.<br>
<span><br>
<br>
> >  No, because udpsink is going to sync the buffers to the clock<br>
> > before sending them. This prevents in the normal case that buffers<br>
> > are sent faster than real-time. For your case (where the input is<br>
> > only provided in real-time anyway), you could also try setting<br>
> > sync=false on the udpsinks but in general that's not recommended<br>
> > and it would be better to find the underlying problem here.<br>
> ><br>
> I have to have sync=true on the sinks otherwise the video and audio<br>
> streams would be offset.<br>
<br>
</span>Offset how? What's the receiver of the stream you're creating there?<br>
<br>
The RTP packets should have exactly the same timestamps, no matter if<br>
you use sync=true or sync=false on the udpsink. However if your<br>
receiver implements RTP wrongly (that is: it ignores RTP timestamps)<br>
then it could get synchronization off indeed.<br>
<br>
The only thing that the sync=false on the udpsink would do is that<br>
packets are sent immediately when they're ready instead of waiting<br>
until their time to be sent arrives. This would potentially cause e.g.<br>
audio packets for time T+10s to be sent at the same time as the video<br>
packets for time T (and that would be a problem!) but if that causes<br>
synchronization problems then your receiver is also doing things wrong.<br>
<br>
<br>
Did you test if outputting the streams on normal sinks instead of<br>
sending them again over the network works as expected? There's no point<br>
in further debugging this without knowing on which side of the pipeline<br>
the problems are introduced.<br>
<span><br>
> Do you suspect that the buffer timestamps downstream of tsdemux are<br>
> derived from the MPEG-TS stream and without taking any consideration<br>
> of the compensation performed by the jitter buffer?<br>
<br>
</span>It would be doing both, but tsdemux might do things in a way that<br>
causes problems here. Try outputting the stream locally and then we can<br>
continue debugging this once we know a bit more where the problem is.<span class="HOEnZb"><font color="#888888"><br>
<div><div><br>
--<br>
Sebastian Dröge, Centricular Ltd · <a href="http://www.centricular.com" rel="noreferrer" target="_blank">http://www.centricular.com</a><br>
<br>
</div></div><br>_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br></font></span></blockquote></div><br></div>
<br>_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br></blockquote></div><br></div>