On 16 Jun 2009, at 21:27, Michael A Dolan wrote:
FYI, I started out in March with a number of comments, some related to multicast UDLR with 1-2 links and I sense that's too big a topic to try and add at this point. My comments therefore have distilled to addressing two major factors in syncing RTP sessions that I believe overshadow the time resolutions being discussed in the draft, and therefore it is an omission not to address them:
1. Common timebase
2. Media-specific access points
I stopped short of suggesting we should design anything. Therefore I still believe both topics belong here, and in this draft, and they are not so big as to defer at this point.
For clarification, I wasn't proposing we define a timebase signaling mechanism (although I do think that's a good idea). All I am proposing is to add some text that explains that a common timebase is needed to achieve anything near the implied sync times discussed in this draft. How the senders and receivers figure that out is out of band. But if they don't and just go along with "wallclock", it makes much of the rest of this draft irrelevant since the timebase error will be huge by comparison.
That's already stated in RFC 3550. I'm not sure it needs repeating here, but can add something if you want.
Regarding the issue about access points, I'm not sure how much background to add, so apologies if this is obvious to everyone. Every media stream type has "access points" that arrive periodically - the point where a decoder can begin to decode the stream. In general, these are a function of the encoding, not constant per type, and not constant per stream. For example in H.264, these typically center around the presence of an IDR frame. HE AAC has a simpler coding structure, but one still can't start decoding anywhere in the stream. The "typical" periods of the H.264 access points range from 0.5 to 2 seconds, depending on the coding. The exact period is application dependent, but is not relevant. The point is that these periods greatly exceed the times shown in the tables which are implied to be the sync times - going as low as 0.04 seconds. The tables in this draft suggesting that RTCP SR packets be sent 0.04 seconds apart for high rate streams. This is interesting (as Thomas notes) for jitter management and clock settling, but that high rate does not help you sync since you can't even start decoding the video for a relatively long time after the 0.04 seconds. This is mostly related to issues of late joiners of course. Therefore, I was suggesting we make note of this fact to clarify there are other factors to sync and acquisition beyond receipt of NTP and the RTCP SR packet, and that these other times far exceed 0.04 seconds.
Okay, that's what I thought you meant. That certainly affects the join times, although I'm not sure I'd call that issue synchronisation latency. We can certainly add some wording to highlight it though.
Co-locating in time the RTCP SR packets with their related access points further improves the sync time. For example, if the IDR is every 2 seconds, there is no benefit (for syncing) to sending the RTCP SR more frequently than that, especially if it is aligned with this access point in time. If the RTCP SR packets are sent randomly in time, the sync time is the IDR period plus 1/2 the RTCP SR packet period, on average. This is more of an optimization, but then, that's what this whole draft is about - optimizing the sync time.
I agree that co-locating the SR information in time with the random access points helps, and will add something to the draft to say that explicitly if it's not already there. I disagree that's sufficient: sending the SR information more frequently gives the receiver more samples from which to estimate any skew between NTP and RTP timestamps, and gives more information to help filter out any incorrect mappings.