Jonathan,

I also agree with you for the live case. For the pre-encoded case, there 
is typically no deviation in the clock contained in the file and the 
media frames do have equidistant timings. Having such an accurate clock 
in the file does help to "tweak" the SR's NTP wallclock value in a way 
that it can be "forced" to be correct. As an example, you may take the 
timing from the file as a scheduler time and put this time + a delta as 
wallclock into your SR, while the SR is actually sent at the 
corresponding gettimeofday() value, which may have deviation from the 
scheduled (wallclock) time.

For the live case, i.e. you have to rely on the system's wallclock only, 
it's different. Your example was the deviations of the win32 get-time 
functions. In such a case with clock deviations around 10ms, there is 
indeed a problem! Even using other clocks as the one of the sound card 
or the one of the video capturer for the wallclock may not really help here.

Possible backward-compatible solutions (assuming the same clock is used) 
may be RTP timestamp alignment or sending RTCP SRs in the multiple 
sessions at the same time including the same NTP wallclock. Everything 
else may lead to inaccuracy in NTP media timestamp generation at the 
receiver. But this seems to be rather an implementation issue than a 
standardization issue. Although this issue may affect the standardization.
I think we should discuss this problem in detail in the draft and show 
what can be done, if no exact clock is available. Even, if not all 
systems are affected, there must be a way to work around such a problem.
Since e.g., the two above proposed solutions would extend the current 
RTP specification for the case of multi session transmission, we do not 
have an informational draft on "multi session transmission issues". It 
would be a normative one, right?

-- 
Thomas Schierl
--------------
Fraunhofer HHI



Jonathan Lennox wrote:
> 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.
> 	
>   

----
Visit us at

IBC 2008 / Amsterdam (NL), 12 - 16 September 2008 / Hall 8 Booth C81
http://www.hhi.fraunhofer.de/index.php?id=2399&L=1

insite 2008 / Johannesburg (South Africa), Sandton Convention Centre / 15 - 17 September 2008 
http://www.insitex.co.za
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt