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

[Gildas Bazin]

On Wednesday 09 November 2005 10:13, Marian Durkovic wrote:
> Hi Sigmund,
> 
>   thanks for your comments and let me add some more info.
> 
> > 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.
> 
> Yes, there are things like 112 kbps or even smaller MP3 streams, and at 
those
> bitrates 3 PCR/PTSs are typically inside one packet - since the streaming
> servers want to send packets close to MTU and not e.g. 300 byte packets.
> But if you don't process every PCR but instead check clock drift once per
> second as I've proposed, this does not matter anymore.
> 
> > My gut feeling tells me a larger cr-average should smooth it better.
> 
> This doesn't seem to be the case. Maybe due to rounding errors, but I've
> identified several streams where increasing CR-average doesn't help, but
> if PCRs are sampled once per second, the stream plays OK. My feeling here 
is
> that if jitter is larger than the interval between two PCRs, things break
> unrecoverably (?) And since NTPd typically uses 64 - 1024 seconds 
intervals
> to sync clocks, I think doing it every 14 - 38 msec is probably not
> necessary anyway.
> 
> > > - 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?
> 
> Well, unfrortunately it's not 40. src/input/input.c seems to be increasing
> this value with relation to caching-time, so if you change caching time
> to something non-standard you'll end up with strange values for 
cr-average.
> I'd at least suggest to remove this relation and use cr-average "as is"
> and set it by default to 100 (40 seems to be too small since packet with
> 80 msec jitter will move the refclock by 2 msec and trigger resampling). 
> Also my first change (clock drift processing only in 1 sec. intervals)
> affects the behaviour significantly, I'd suggest to re-test streams that
> currently need high cr-average values, since this might not be needed
> anymore (at least all "suspect" streams on the multicast internet now
> play fine without touching cr-average).
> 

The relation between cr-average and time caching is actually very sensible.

Data caching is mainly a way to cope with streams which have unreliable 
sending rates (be it network/server latency, jitter, bursts, etc...). Now 
if you need heavy caching, that more than likely means you have large 
changes in your receiving rate, so you'll want to increase cr-average to 
smooth out these changes.

This is why the default caching in the udp access module is pretty low (udp 
is mostly used for reliable / low delay streaming), while you have a high 
caching value for http.

I do agree that the problems you raise need to be fixed, although I don't 
think your fixes are appropriate.

The clock synchro algo is there to keep the playback speed synchronised with 
the server, not only to avoid buffer underruns / overruns, but also to keep 
a low delay from the server (depending on the value of caching set by the 
user).

The problem with VLC's clock is that it does its synchro by comparing the 
time of arrival of data with the timestamp set on it by the server, aka the 
PCR (which btw is why the prebuffering introduced lately might not be such 
a good idea).
This method is appropriate for very low delay streaming which doesn't have 
much jitter and bursts in the transmission, but it isn't for anything else 
(and remember, VLC was designed as an intranet streaming client).
If VLC is allowed to cache enough data, then a more sensible way to do this 
synchro is to actually look at how much data we have in our cache (in units 
of time), and if this value is above or below some treshold then start 
adapting the clock. It might still be interesting (or not) to keep using 
the current synchro algo for very low delay streams though.

There are plans to rewrite the clock to solve all of this (and more, like 
the pause delay, the initial caching delay, etc...) but nobody has found 
the time to do it yet.

Where I don't find your patch acceptable is that it makes assumptions about 
the kind of streams you are receiving. For instance checking the PCR  every 
seconds means you don't care about low delay. Using a variable cr-average 
is imo much better.
And discarding PCRs which are too early or too late by 80ms is a bit extreme 
as well. What if the server and client are really out of sync by that much 
or more ?

--
Gildas

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