Re: [AVT] alignment of layers issue

[Randell Jesup <rjesup at wgate.com>]

Magnus Westerlund <magnus.westerlund at ericsson.com> writes:

>Jonathan Lennox skrev:
>> Magnus Westerlund writes:
>> I'm curious, also, how many existing implementations actually get this
>> right.  Every implementation I've found of SRs either a) uses
>> gettimeofday() or equivalent, and is thus subject to the whims of system
>> clock precision, or b) establishes an NTP/RTP mapping once at startup
>> and never changes it, making SRs useless for lip sync if there's any
>> clock skew at all.
>
>Very good question. I am not really running any real systems out there.
>For most application B is actually better than A, it might affect the
>buffering badly for low delay applications. I guess most streaming
>servers never care to adjust anything.

B is often implemented - but is WRONG, unless the application *knows* the
two streams share a clock base, and can never shift in relative sync no
matter what.  The might be the case for some non-live audio/video sources.

gettimeofday() coarseness - this is an issue (idiots who built the old PC
hardware (and DOS/Windows) and the bigger idiots who let that remain the
default for 25+ years...).

However, 16ms coarseness on the order of 2.5-7.5s updates would be in the 
range of 0.64%-0.213%, or at most just over 1/2 of a percent.  Relevant but
not major, and it should only come into play for sync.

Certain applications and UAs, though (*cough*Asterisk*cough*) can send you
RTCP packets that imply huge, wild shifts in NTP<->timestamp rates, like an
RTCP that says 40ms, or even 0ms(!), or -120ms (!!!!!)  have occured since
the last RTCP, but 40000 (or 450000) samples have occurred.

There are a few real-world cases to watch out for with system-time calls,
like what happens if a small NTPd adjustment is being made periodically, or
a large (seconds, minutes) NTPd-derived time change occurs during the life
of the stream, or if the user changes the system time (on a
non-NTPd-enabled system), or at daylight savings time (which *should* have
no effect if you're using TZ's properly, but could be bad if someone is
handling DST by hand.  These can even bite case B (with a much smaller
window), since two streams will sample gettimeofday() at different points,
potentially at different sides of a clock change.

Ugh.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt