Re: [AVT] accepting draft-lakaniemi-avt-rtp-evbr-02 as WG item

If we may still discuss this issue - I would say I fully agree with Jonathan. 

BR, YK 

>-----Original Message-----
>From: ext Jonathan Lennox [mailto:jonathan@vidyo.com] 
>Sent: 04 September, 2008 00:31
>To: Colin Perkins
>Cc: Stefan Döhla; thomas.schierl@hhi.fraunhofer.de; Wang 
>Ye-Kui (Nokia-NRC/Tampere); avt@ietf.org
>Subject: RE: [AVT] accepting draft-lakaniemi-avt-rtp-evbr-02 as WG item
>
>Colin Perkins writes:
>> > If you're sending live (as opposed to pre-recorded) media, clock
>> > drift between the media clock (generating RTP timestamps) and the
>> > system time-of-day clock (generating NTP timestamps) can make
>> > sample-accurate stream alignment based on RTCP SRs extremely
>> > problematic, especially as RTCP report intervals lengthen.
>> >
>> > Specifically, assuming each RTCP SR's NTP and RTP times accurately
>> > represent the time-of-day and sample-clock measurements
>> > (respectively) at SR transmission time, and SR transmission time is
>> > randomized independently for each RTCP session,
>> > max_sample_misalignment = max_rtcp_interval * abs(actual_clock_rate
>> > - nominal_clock_rate)/nominal_clock_rate.
>> 
>> I'm not sure this expression is valid, since I'd expect the receiver
>> to estimate the clock skew based on observing several SR's, and
>> compensate for it.
>
>I think this may be the disconnect we're seeing here.  It's 
>fine for synchronization for lip sync to be estimated 
>approximately sometime shortly after session startup, and 
>slowly converge to greater precision over time as you receive 
>more SRs.  Lip sync also degrades gracefully if the encoder's 
>clocks are inaccurate or imprecise.
>
>Layered codecs, by contrast, are *not decodable* until you've 
>established the timing relationship between the layers, unless 
>you use codec-specific in-band methods such as SVC's NI-C or 
>I-C which avoid the use of timing information entirely.  
>Otherwise, if your receiver mis-calculates a timing 
>relationship between streams you end up with garbage output 
>from your decoder.
>
>I think that for layered codecs, the requirements (100% 
>accurate clock synchronization prior to any decoding) and the 
>domain constraints (a single common media clock, as I argued 
>in my previous e-mail) are sufficiently different from those 
>of lip sync that it's not unreasonable to have a specific 
>solution to the problem, rather than trying to re-use a 
>solution to a different problem which has different 
>requirements and constraints.
>	
>-- 
>Jonathan Lennox
>Vidyo, Inc
>jonathan@vidyo.com
>
>
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt