[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txt

Hi Ye-Kui,

Ye-Kui Wang wrote:
And the last one: What was wrong again with
signaling/knowing that two
streams come from the same source/encoder and would be perfectly aligned after reception of one NTP-RTP mapping per stream or even directly aligned (same RTP timeline)? I tried to find the answer in the list archive, but maybe you can give me a hint. 


The main issue was backward compatibility.


I also need some refreshing of my memory. Is the backward compatibility
issue the one like "Timing based synchonization of RTP flows must be based
on RTCP SRs according to RFC 3550", or something else?
The other point was not to allow receiver implementations which break the SR-based approach. 


Another point just came to my mind. When we were discussing other possible
mechanims based on RTP header extentions, e.g. by including something like
decoding order numbers, there was an argument that the mechanim MUST work if
the optional RTP header extensions are removed by intermediate network
elements. How does that argument relate to the RTP header extension mechanim
in this draft?
I guess that has been discussed earlier. See, e.g., http://www.ietf.org/mail-archive/web/avt/current/mail17.html 
There was also more discussion on the list in December 2008.
I think, if there is a middle box which does not know about the new layered codec and hence does not know about the new header extensions, such device wouldn't do anything reasonable with the layered media anyway. So, I cannot see an issue. 


Thomas



BR, YK


-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Thomas.Schierl at hhi.fraunhofer.de 
Sent: Friday, March 13, 2009 7:34 AM
Cc: avt at ietf.org WG; Colin Perkins
Subject: Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txt 

Hi Stefan,

Stefan Döhla wrote:

Colin, Thomas, all,
the draft is describing the proposed header extension and RTCP SR request quite good, however:
Isn't the NTP timestamp generation subject to the same
problems as in
RTCP? I could easily send an RTCP SR as well for every RTP packet within a sampling instance of one (in terms of RTP time),
i.e. there
could be an RTP packet and an RTCP SR packet containing the
same RTP
timestamp if I were able to generate them virtually at the
same time
(just a few ns away). Clearly, this is not datarate-efficient nor sensible, but I don't see a big difference to the proposed approach.
So what about the source for the NTP time: Should the NTP time be filtered at the sender before inclusion into the HDR_EXT?
Because if
not, the NTP timestamp would either be only related to the RTP timeline (bad - then we have two different timelines, one via RTCP, the other in the HDR_EXT) or be jittery (bad because not instantly useful, though the same timeline as RTCP).
Here it is important to use the same NTP timestamp value for the same point of synchronization in all the sessions. This is only guaranteed, if such header extensions are used for the same sampling time instance in all the sessions, i.e. using the same NTP wallclock timestamp. I think this is stated in the draft.
An additional comment on the draft is that section 4.3 is quite complex and hard to understand, though (I think) correct.
It is anyway planned to spend some more work on this section. I try to improve the text.
And the last one: What was wrong again with
signaling/knowing that two
streams come from the same source/encoder and would be perfectly aligned after reception of one NTP-RTP mapping per stream or even directly aligned (same RTP timeline)? I tried to find the answer in the list archive, but maybe you can give me a hint. 


The main issue was backward compatibility.

Thomas


Cheers
- Stefan


Colin Perkins schrieb:
The 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:

From: 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.org
A 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-09
This memo outlines how RTP multimedia sessions are
synchronised, and
discusses how rapidly such synchronisation can occur. We
show that
most RTP sessions can be synchronised immediately, but
that the use
of video switching multipoint conference units (MCUs) or large source specific multicast (SSM) groups can greatly increase the initial synchronisation delay. This increase in delay can be unacceptable to some 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 RTP
Profile for
RTCP-based Feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Two new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp based decoding order recovery for layered codecs in the 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-announce
Internet-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

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