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

["Ali C. Begen (abegen)" <abegen at cisco.com>]

> -----Original Message-----
> From: Ye-Kui Wang [mailto:yekuiwang at huawei.com]
> Sent: Saturday, June 20, 2009 2:13 PM
> To: Ali C. Begen (abegen); 'Colin Perkins'; 'Michael A Dolan'
> Cc: avt at ietf.org
> Subject: RE: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txt
> 
> 
> > Have you considered sending an SR as a part of the unicast
> > burst (or RAMS-I message that describes the burst) that we
> > provide for rapid acquisition? We may end up sending an SR
> > this way since it will be required for figuring out the
> > extended seqnums.
> >
> 
> And the SR herein can also help the RR to fastly establish a-v sync.
> However, I think there is no need to make the SR part of the RAMS-I message
> (i.e. to change the RAMS-I syntax to include the information the SR
> carries), as you can use a compound RTCP packet to include both the RAMS-I
> and the SR. Of course you may meant for this.

Yep, no need to change the RAMS-I format. I meant compound packet.

-acbegen

 
> BR, YK
> 
> > -----Original Message-----
> > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
> > Behalf Of Ali C. Begen (abegen)
> > Sent: Wednesday, June 17, 2009 2:36 PM
> > To: Colin Perkins; Michael A Dolan
> > Cc: avt at ietf.org
> > Subject: Re: [AVT] Fwd: I-D
> > Action:draft-perkins-avt-rapid-rtp-sync-03.txt
> >
> > Hi Colin,
> >
> > > 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.
> >
> > That is part of something we call "acquisition delay" and
> > this problem is addressed in a separate draft:
> > http://tools.ietf.org/id/draft-ietf-avt-rapid-acquisition-for-
> > rtp-01.txt
> >
> >
> > > 	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.
> >
> > Have you considered sending an SR as a part of the unicast
> > burst (or RAMS-I message that describes the burst) that we
> > provide for rapid acquisition? We may end up sending an SR
> > this way since it will be required for figuring out the
> > extended seqnums.
> >
> > -acbegen
> >
> >
> > > -----Original Message-----
> > > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
> > Behalf Of
> > > Colin Perkins
> > > Sent: Wednesday, June 17, 2009 10:57 AM
> > > To: Michael A Dolan
> > > Cc: avt at ietf.org
> > > Subject: Re: [AVT] Fwd: I-D
> > > Action:draft-perkins-avt-rapid-rtp-sync-03.txt
> > >
> > > Michael,
> > >
> > > 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.
> > >
> > > --
> > > Colin Perkins
> > > http://csperkins.org/
> > >
> > >
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt at ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
> >
>