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