[vlc-devel] Re: Clock synchro problems - proposed solution
gbazin at videolan.org
Wed Nov 9 22:38:10 CET 2005
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
> 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
> that if jitter is larger than the interval between two PCRs, things break
> unrecoverably (?) And since NTPd typically uses 64 - 1024 seconds
> 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
> > 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
> 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
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 ?
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
More information about the vlc-devel