[Live-devel] Clock drift compensation

[Gilles Chanteperdrix]

On 12/24/2013 03:42 AM, Ross Finlayson wrote:
> No, although you're sort of on the right track (because the RTCP "SR"
> arrival times can be used to compute the network 'jitter' (see RFC
> 3550) - and FYI in LIVE555 this jitter computation is made available
> to clients via the "RTPReceptionStats" database).
> 
> The way for a client to detect (and compensate for) the drift between
> the server and client clocks is to monitor the size of the client's
> playout buffer.
> 
> If the playout buffer keeps increasing over time, then the server's
> clock is faster than the client's.  The client can compensate for
> this by playing out frames faster, or perhaps by dropping frames
> occasionally.
> 
> If the playout buffer keeps emptying - despite starting at a
> reasonably large level (to allow for network jitter) - then the
> server's clock is slower than the client's.  The client can
> compensate this for playing out frames slower, or perhaps by
> duplicating frames occasionally.

Makes sense, Ok.

> 
> 
>> Now, the question is: what is the best place to implement this? In
>> the application?
> 
> Yes - in the media player application (in particular, by monitoring
> its playout buffer).  But do you really want to bother with this?
> VLC is only one of the many media players out there (and you've
> already dealt with their developers :-).  I thought your project was
> to develop a server?

This is a separate project. The server is almost finished anyway.

Thanks.


-- 
                                                                Gilles.