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