<br><br><div class="gmail_quote">On Thu, Apr 22, 2010 at 4:31 PM, Attila RS <span dir="ltr">&lt;<a href="mailto:avgrind911@gmail.com">avgrind911@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I&#39;m having some trouble getting playback of live streams to synchronize correctly (especially if playback is started in the middle of a stream). The way segments (start/stop/position time), base time and buffer timestamps are used in gstreamer is not completely clear to me. So a basic explanation of how synchronization is intended to operate in gstreamer would be helpful.<div>

<br></div><div>In the past for other applications I have done the following for something like transport stream encapsulated media: The demuxer would get PTS/DTS time for each frame and associate it with the frames buffer (gstreamer essentially does the same). The demuxer would also take the current PCR value from the stream and subtract the current system time to get a time-offset and associate that with the buffer as well (gstreamer doesn&#39;t do this). The buffer then gets passed along to decoders and render elements. Then the render element get a buffer it gets the current system time and adds the time-offset from the buffer to get the current PCR time. The current PCR time is then compared to the buffers PTS to see if it is time to render or not.</div>

<div><br></div><div>Since an offset or diff time is not passed along with each buffer in gstreamer it is a bit unclear to me exactly how a sink element will be able to get the current pcr time.</div><div><br></div><div>As it stands now in gstreamer the PTS values associated with a frame are passed along as expected and match the values in the stream, but they are compared to the running time, which ends up always starting from 0. I get something like the below from the display sink.</div>

<div><br></div><div><div>basesink gstbasesink.c:1826:gst_base_sink_get_sync_times:&lt;play_video&gt; got times start: 0:13:16.422277777, stop: 0:13:16.455644443, do_sync 1</div><div>basesink gstbasesink.c:1991:gst_base_sink_wait_clock:&lt;play_video&gt; time 0:00:02.848977777, base_time 3:51:48.648315390</div>

<div>basesink gstbasesink.c:2842:gst_base_sink_render_object:&lt;play_video&gt; buffer late, dropping</div></div><div><br></div><div>I&#39;m assuming the demux plugin (mpegtsdemux) isn&#39;t setting the stream position correctly. The time value printed above should be equal to the current PCR time. </div>

<div><br></div></blockquote><div>Well after some more digging it looks like the above time print is intended to be a offset time value from the base time set by the received segment. I modified the prints to display the current time read from the clock and the desired render time. This showed that the frames were actually arriving late. The question now is why the live stream with an udp/rtp source runs so much slower than a file source. Playing the stream from something like mplayer or VLC and it plays fine.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div></div><div>Anyway any help with what the plugins should be doing and how best to proceed would be appreciated.</div>
<div><br></div><font color="#888888"><div>Attila</div>
</font></blockquote></div><br>