Re: [AVT] alignment of layers issue

[<gerard.babonneau at orange-ftgroup.com>]

Hi

I want first to remenber I wrote in the past that layer alignment with RTCP/SR may need a long time that providers get irritated with for hight quality IPTV programs. This is also, in a very different way, the main objective of draft-versteeg-avt-rapid-synchronization-for-rtp-

Even if RTCP/SR are possible in multicast sessions, the problem of a rapid layer alignment persits because RTCP and RTP are indeed companion session, but independant in sending messages.

In my understanding, layer alignment (and synchronisation) is more strictly a RTP problem rather than a control of the session (in my RTCP understanding). So, an efficient synchronisation process could be a layer alignment precisely when starting the send of a IDR. RTP according to the payload content has enough information to do it. Thus, a receiver can immediately decode multiple layers from the first IDR it receives.

So timestamp alignment is from a long way the best. Even if timestamp is random, I can convince that hazardously an encoder or a svc video source can set the same timestamp in at least two sessions relating to a unique video encoding. I see no reasons that could stop RTCP in a such case.

However, if timestamp alignment is fine for SVC, my very little problem is that I do not clearly understand how this can run to synchronize sessions from several sources that cannot share the same timestamp. The perfect should be another generic solution to invent, that could apply to every multi-session encoders.

Best regards,

Gérard BABONNEAU 


-----Message d'origine-----
De : avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] De la part de Ingemar Johansson S
Envoyé : jeudi 20 novembre 2008 17:11
À : Randell Jesup; Magnus Westerlund
Cc : Ingemar Johansson S; Jonathan Lennox; schierl at hh.fgh.de; avt at ietf.org; csp at csperkins.org
Objet : 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
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt