[vlc-devel] Re: Clock synchro problems - proposed solution

[Sigmund Augdal Helberg]

On Wed, 2005-11-09 at 09:20 +0100, Marian Durkovic wrote:
> Hi all,
> 
>    after various tests with different streams seems I've found the reasons
> why the synchro has stability problems:
> 
> 1) the interval for computing clock drift is too small. Clock drift is
> currently computed at every PCR - and PCR interval for various streams I have
> here is typically between 14 and 39 msec. This is sometimes much less than
> network jitter and for small audio streams it means that e.g. 3 different PCRs 
> included in the same RTP/UDP packet corrupt the clock drift computation.
> Also for streams with variable bitrate, the computation is not accurate, since
> due to prebuffering, clock drift is computed from data upto 100 msec in the 
> past. Also, due to relatively small time differences I suspect this
> calculation suffers also from rounding problems.
The clock drift calculation smoothing algorithm is basically a running
average with cr-average being by default 40. This means that even though
the calculation is performed at every pcr at least 40 pcr periods are
taken into account. Increasing cr-average will increase the period. The
computation is indeed subject to rounding error, and I have a still
uncommited patch that fixes this. As for several pcr at once this is an
error and at least vlc will output a warning if sends such a packet, but
vlc is not the only source of streams for vlc to read, so we should
probably do an attempt to handle this gracefully. My gut feeling tells
me a larger cr-average should smooth it better.

I'm also somewhat suspicious of the initialzation of the current code.
As you say prebuffering is not taken into account, also the running
average is (iirc) initialzed to zero meaning the cr changes will be too
small for the first few pcrs until the averaging converges (which may
never happen in some extreme cases due to rounding errors). This used to
be different but it was changed (by gibalou) because the old code was
very sensitive to jitter at the start of playback. I think we should
guess the initial value for cr_delta from some info, but I don't know
what.

> 
> 2) sometimes the OS on either sender or receiver machine randomly delays the
> RTP/UDP packet and this delay is in the order of hundreds of miliseconds.
> If this is included in the clock drift calculation, it moves the reference
> clock that much, that VLC immediately starts audio resampling and/or drops
> the buffer due to PTS being out of range. 
This does indeed sound useful, we had a similar problem with a running
average in the vout core some time ago where scheduler jitter would mess
up the estimated decoding time to such an extent that decoding would
never again recover.

> 
> 
>   Please have a look at the attached patch, which tries to solve the above
> problems by:
> 
> - extending the clock drift computation interval to 1 second,
I didn't look that much on this part just yet, perhaps I'll do it again
later.
> - using 100 as hardcoded value into smoothing alg. to avoid rounding problems
I don't see how this would help anything. What makes 100 better than 40
for avoiding rounding errors? Is it worth sacrificing support for all
those streams requiring larger cr-average? Anyway, I have a proper fix
for this I will apply some time.
> - ignoring extreme clock difference values ( > 80 msec )
This is probably a good thing, but please wait for other people to
comment as well, as this is quite core code.
> 
>    Any comments are of course welcome.
> 
> 
> 	With kind regards,
> 
> 
> 		M.
> 
> --------------------------------------------------------------------------
> ----                                                                  ----
> ----   Marian Durkovic                       network  manager         ----
> ----                                                                  ----
> ----   Slovak Technical University           Tel: +421 2 524 51 301   ----
> ----   Computer Centre, Nam. Slobody 17      Fax: +421 2 524 94 351   ----
> ----   812 43 Bratislava, Slovak Republic    E-mail/sip: md at bts.sk    ----
> ----                                                                  ----
> --------------------------------------------------------------------------

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html