Re: [AVT] Some comments to subsection 8.1.1 indraft-ietf-avt-rtp-svc-08

[Randell Jesup <rjesup at wgate.com>]

Colin Perkins <csp at csperkins.org> writes:
>Synchronisation and timestamp mapping across sessions is a standard  
>part of RTP. Again, no new mechanisms are needed.

It is standard, but its use in SVC is slightly unusual, since normally
there's an assumption in RFC 3550 that there can be timestamp drift between
two RTP streams, even if they come from the same source (and normally you
don't really know where they come from).  For example, with two audio
channels, both at 8000Hz sampling, both from the same endpoint, you'll get
RTCPs that lock both of their RTP timestamps to NTP - but the two streams
could drift relative to each other, because they might be sampled off
different clocks/crystals/devices.

In SVC, there's an additional constraint that all the related streams are
based off the same sampling timeline and clock, then converted to RTP
timestamps for each stream.  The timestamps (per RFC 3550) should have
random startpoints, but the RTCP packets will (once received!!) lock the
streams together, with no drift.

I would expect it makes sense to have about one sentence mentioning that
the base NAL sampling times used to generate the RTP timestamps all come
from the same source timeline, since that's not normally a constraint in
3550.

-- 
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