[gst-devel] live stream synchronization

[Attila RS]

On Thu, Apr 22, 2010 at 4:31 PM, Attila RS <avgrind911 at gmail.com> wrote:

> I'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.
>
> 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'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.
>
> 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.
>
> 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.
>
> basesink gstbasesink.c:1826:gst_base_sink_get_sync_times:<play_video> got
> times start: 0:13:16.422277777, stop: 0:13:16.455644443, do_sync 1
> basesink gstbasesink.c:1991:gst_base_sink_wait_clock:<play_video> time
> 0:00:02.848977777, base_time 3:51:48.648315390
> basesink gstbasesink.c:2842:gst_base_sink_render_object:<play_video> buffer
> late, dropping
>
> I'm assuming the demux plugin (mpegtsdemux) isn't setting the stream
> position correctly. The time value printed above should be equal to the
> current PCR time.
>
> 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.


> Anyway any help with what the plugins should be doing and how best to
> proceed would be appreciated.
>
> Attila
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20100422/f20ca9a8/attachment.htm>