Ye-Kui Wang wrote:
Some more comments in addition to those from others posted earlier. Section 1: Two backwards compatible extensions to the basic RTP synchronisation mechanism are proposed: o An enhancement to the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF) [2] is defined to allow receivers to request additional RTCP SR packets, providing the metadata needed to synchronise RTP flows. This can reduce the synchronisation delay when joining sessions with large RTCP reporting intervals, or in the presence of packet loss. o Two RTP header extensions are defined, to deliver synchronisation metadata in-band with RTP data packets. These extensions provide synchronisation metadata that is aligned with RTP data packets, and so eliminate the need to estimate clock-skew between flows before synchronisation. They can also reduce the need to receiveRTCP SR packets before synchronising flows.The two extensions seem to be a bit contradicting to each other. The benefit of the first is to allow receivers to request more SR packets, while one can be reduce the need of SR packets. How to use them both? If only one should be used at a time, when to use which? Are both really needed?
We think depending on the use case, both can be helpful. For fast tune-in A/V sync with having a backward channel, the first method is to favor. If exact matching of NTP timestamps is required as for timestamp-based decoding order recovery for layered codecs, the second is in favor.
Section 2.1.2:
Session| Number of receivers (single sender assumed):
Bandwidth| 2 3 4 5 10 100 1000 10000
--+------------------------------------------------
8 kbps| 2.73 4.10 5.47 5.47 5.47 5.47 5.47 5.47
16 kbps| 2.50 2.50 2.73 2.73 2.73 2.73 2.73 2.73
32 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50
64 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50
128 kbps| 1.41 1.41 1.41 1.41 1.41 1.41 1.41 1.41
256 kbps| 0.70 0.07 0.07 0.07 0.07 0.07 0.07 0.07
512 kbps| 0.35 0.35 0.35 0.35 0.35 0.35 0.35 0.35
1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.18 0.18 0.18
2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.09 0.09 0.09
4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04
Figure 1: Average RTCP Reporting Interval (seconds)
It seems that the number 0.70 for 512 kbps with 2 receivers is typo (of
0.07)?
If you mean the 256kbps line, I think yes.
Section 3.2.Two variants of RTP header extension are specified, with the difference being whether to signal the 8 MSBs of the integer part of the NTP timestamp. I think having either but only one of the two variants, preferrably the onewithout the 8 MSBs, is enough.
This may be correct, although this version is not compliant with ISMA. Thomas
BR, YK-----Original Message-----From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Colin PerkinsSent: Monday, March 09, 2009 3:43 PM To: avt at ietf.org WG Subject: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txtThe changes in this version are primarily editorial; we're aware that not all the open issues have been addressed yet. Any further comments are welcomed.Chairs: we'd like this to be considered as an AVT working group draft, as indicated privately.Cheers, Colin Begin forwarded message:synchronised, andFrom: Internet-Drafts at ietf.org Date: 9 March 2009 17:15:02 GMT To: i-d-announce at ietf.org Subject: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txt Reply-To: internet-drafts at ietf.orgA New Internet-Draft is available from the on-line Internet-Drafts directories.Title : Rapid Synchronisation of RTP Flows Author(s) : C. Perkins, T. Schierl Filename : draft-perkins-avt-rapid-rtp-sync-03.txt Pages : 17 Date : 2009-03-09This memo outlines how RTP multimedia sessions arediscusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but thatthe use ofvideo switching multipoint conference units (MCUs) or large source specific multicast (SSM) groups can greatly increase the initial synchronisation delay. This increase in delay can beunacceptable toProfile forsome applications that use layered and/or multi-description codecs.This memo updates the RTP Control Protocol (RTCP) timing rules to reduce the initial synchronisation delay for SSM sessions. A new feedback packet is defined for use with the Extended RTPRTCP-based Feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Two new RTP headerextensions aredefined to allow rapid synchronisation of late joiners, andguaranteecorrect timestamp based decoding order recovery for layeredcodecs inthe presence of clock skew. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-perkins-avt-rapid-rtp- sync-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.Content-Type: text/plain Content-ID: <2009-03-09100610.I-D at ietf.org> _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt_______________________________________________ Audio/Video Transport Working Group avt at ietf.org https://www.ietf.org/mailman/listinfo/avt_______________________________________________ Audio/Video Transport Working Group avt at ietf.org https://www.ietf.org/mailman/listinfo/avt
---- Visit us at OFC 2009 / March 24-26 / San Diego, California / Hall B1, Booth 411 http://www.ofcnfoec.org/ Web 2.0 Expo / March 31 - April 03 / San Francisco, California / Booth 415 http://www.web2expo.com/webexsf2009