[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] alignment of layers issue
Hi
My comment (based on Randell's real life observation below) is that I really don't see the conflict between RTCP SR and RTP timestamp alignment as proposed by Thomas and Jonathan.
I believe nobody wants to get rid of RTCP SR (or RTCP whatever). RTP timestamp alignment is simply to be seen as an enhancement to make sure that sample (or decoding block) alignment is ensured with 100% probability for multi-layer/view/channel codecs. RTCP (SR) is needed for lipsync with other media and SSRC collision detection. My gut feeling is that, given all the possible implementation aspects with RTCP SR that there are simply too many loose ends to make it trustworthy for the exact alignment requirement with e.g layered codecs.
Also.. (IMHO very important). As it may be really tricky (or impossible) for the decoder to know if layers are aligned the "alignment device" must guarantee a near 100% successrate.
The RTP timestamp alignment proposal can in my opinion guarantee 100% success rate.
RTCP SR: I can't help getting the feeling that the failure rate may in some cases be quite high (depending on a whole lot of implementation issues). Additionally, what if there is an RTCP SR alignment tune in period of several seconds on session start of when the channel is switched ?. Is it acceptable to just decode the base layer for that long period, one cannot take the chance to add the enhancement layers until it is deemed near 100% safe to do so. And a last one...when is RTCP SR alignment tune in done and safe ?, as the receiver side doesn't really have a reference it must rely on some metrics that with a given probability tells that the alignment is correct and this by its nature introduces an element of uncertanity.
My 99 cents
/Ingemar
________________________________
Från: Randell Jesup [mailto:rjesup at wgate.com]
Skickat: on 2008-11-19 20:24
Till: Magnus Westerlund
Kopia: Jonathan Lennox; Ingemar Johansson S; avt at ietf.org
Ämne: Re: [AVT] alignment of layers issue
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