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

Sigmund Augdal Helberg dnumgis at videolan.org
Thu Nov 10 10:23:49 CET 2005

On Wed, 2005-11-09 at 20:57 +0100, Marian Durkovic wrote:
> Hi Sigmund,
> > 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.
>   thanks for commiting the rounding-error fix. Indeed, with this fix, it's
> enough to change the computation interval to 1 second, and my test streams
> play all fine. 
>   Please find the new - now much simpler version of my synchro patch in the 
> attachment. 
This patch is indeed much cleaner, but even if everyone agreed that this
was the right way to go, I don't think this is the right place to
implement it. The function changed is called input_ClockSetPCR and is
part of the very core of vlc, so I think it should really set pcr, as
that is it's name. If you want some pcrs to be ignored you should rather
update whatever calls this function to do the pcr ignoring. In your case
it would seem that this is the mpeg2 ts demuxer. I think handling cases
like having several PCR in the same packet would be much easier from the
ts demuxer. I guess the same is the case for the from the OSes IO-jitter
you talk about.


> 	With kind regards,
> 		M.

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 mailing list