<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">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">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 class="">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 class=""><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 class=""><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.<br>
<div class="HOEnZb"><div class="h5"><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">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></blockquote></div><br></div>