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

[Marian Durkovic]

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).


	With kind regards,

		M.


--------------------------------------------------------------------------
----                                                                  ----
----   Marian Durkovic                       network  manager         ----
----                                                                  ----
----   Slovak Technical University           Tel: +421 2 524 51 301   ----
----   Computer Centre, Nam. Slobody 17      Fax: +421 2 524 94 351   ----
----   812 43 Bratislava, Slovak Republic    E-mail/sip: md at bts.sk    ----
----                                                                  ----
--------------------------------------------------------------------------

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