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