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

[Gildas Bazin]

On Thursday 10 November 2005 09:00, Marian Durkovic wrote:
> > >   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.
> 
> Well, I don't think this would be possible, since input_ClockSetPCR is 
doing
> a lot of actions before it tries to update the cr_delta. I'm afraid those
> actions should be performed for every PCR, or?
> 

Indeed. For instance you need to be able to detect clock wrap-around / 
reset  / gaps.

>
> The real problem here is the cr_delta being updated too frequently which
> breaks the reference time base - even on a local LAN since OS IO-jitter is 
> unavoidably present at both sender and receiver. So it's only this single 
> action which needs to be performed at different intervals - e.g. once per 
> second.
> 

As I told you earlier, I don't think this is the right solution. It doesn't 
completely remove problems associated with jitter (since the algo is still 
using the receiving time) and will make the clock changes less responsive.

However I will agree that it should be overall better than the current algo 
if you can lower your PCR sampling time to a more sensible value. An 
averaging period of 40s is imho not acceptable but a sampling rate of 100 / 
200 ms should be good enough.

--
Gildas

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