Network Clocks synchronize very slowly after long delay

Kevin Boos kevinaboos at gmail.com
Mon Sep 15 12:49:39 PDT 2014


Hi Nicolas,

Thanks for the suggestion, I’ve looked into Aurena’s code but I’m not quite sure about setting up the base time on the client properly.

How exactly should I "adjust the base time to compensate” for the initial seek?  On the server, I’m getting the pipeline’s current clock time (the base time), sending that base time to the client, and then seeking to that point on the client. I’m confused as to what the base time of the client’s net clock should be after I’ve executed the seek operation.

Thanks,
Kevin

On Sep 2, 2014, at 8:59 PM, Nicolas Dufresne <nicolas.dufresne at collabora.com> wrote:

> 
> Le 2014-09-02 19:48, Kevin Boos a écrit :
>> Hello all,
>> 
>> I’m using network clocks to synchronize video playback across one server and many clients. The synchronization itself works well, but it takes a very long time before things actually sync up.
>> 
>> For example, I’ll start the server video, and then connect each client one-by-one. If I connect a client when the server video is towards the beginning (i.e., after only a few seconds), the client video will almost instantly snap to the correct point in its local video playback and then continue to play in a properly synchronized fashion with the server. BUT, if I wait for a bit, maybe 10-60 seconds, and then try to connect a client, that client will take quite a long time before it snaps to the correct point in the video and plays in sync.
>> 
>> So, the further along the server video is, the longer it takes the client video to catch up. This is such a strange phenomenon, and it negatively affects the viewing experience quite a bit. For example, if the server video is at the 1:30 mark when I connect a client, that client takes around 25 full seconds before it becomes in-sync. I can see in the GStreamer logs that, during this 25-second waiting period, frames are being dropped because “there may be a timestamping problem” or “this computer is too slow.” Again, this problem does not happen if I connect a client at the very beginning of the server video’s playback (or I guess it happens so quickly that it’s unobservable).
> I've implement quick sync for synchronized playback already in Aurena [1]. Please have a look, and come back if you have questions. The reason you get this is that when late, GStreamer just keep dropping decoded frames. Though, decoder might not be fast enough to ever catch up. This apply to seekable stream, where seeks are performed by the clients (hence the playback starting at start). The solution is seek close (ideally slightly after) the current position and adjust the base time to compensate.
> 
> cheers,
> Nicolas
> 
> [1] https://github.com/thaytan/aurena
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



More information about the gstreamer-devel mailing list