[vlc-devel] Re: vlc: svn commit r13220 (md)
gbazin at altern.org
Sun Nov 13 14:59:44 CET 2005
On Sunday 13 November 2005 12:42, Marian Durkovic wrote:
> The original comparision was trying to directly compare microsecond units
> with PCRs, which obviously can't be done.
Where did you see that CR_MAX_GAP was in microseconds ?
It isn't. It's a value in 90Khz units and it was empirically determined to
provide a sensible clock GAP detection.
> Thus the limit for detecting PCR-gaps (on e.g. broken streams edited by
> dd) was 22,2222 seconds instead of 2 seconds.
Yep, 22 seconds was exactly what was wanted.
Assuming you'll always have less than 2 seconds between 2 received PCRs
isn't sensible. It might be for well formed MPEGs but it won't be for other
kind of streams.
> > I don't see how the detection of input clock gaps could be related to
> > our internal clock.
> Since the gap in PCRs was not detected, the code computing delta_cr was
> thinking it's a clock drift between sender and receiver and trying to
> "compensate" it upto 22 seconds. Now, the PCR gap > 2 seconds is properly
> detected and a new reference point is recomputed.
That still doesn't explain why the clock gap detection uses i_rate. i_rate
has nothing to do with the input clock, it's only relevant for our internal
> > And even if it was, your calculation seems very odd to me since i_rate
> > actually fixed point with a denominator of DEFAULT_RATE.
> I've taken the computation from ClockToSysdate() and took into account
> 27000/300=90, so I'm doing exactly the same computation. If
> is doing things wrong, then we of course need to fix both computations.
What you're doing wrong is, as I already stated, that you can't do input
clock gap detection based on our internal clock.
The input clock gap detection is supposed to be based on the input clock and
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