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

[Ye-Kui Wang <yekuiwang at huawei.com>]

Hi Stefan,

> Then I think my assumption was correct, that you need to 
> pre-filter the NTP timestamps so that they increase roughly 
> linearly - but at least monotonically with each according RTP 
> timestamp - otherwise it would be possible to align samples 
> from several layers but it is no more guaranteed that they 
> have the timestamps in correct order).

I need an example to follow you here :-)

BR, YK 

> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On 
> Behalf Of Stefan D?hla
> Sent: Friday, March 13, 2009 9:40 AM
> To: Thomas.Schierl at hhi.fraunhofer.de
> Cc: Colin Perkins; avt at ietf.org WG
> Subject: Re: [AVT] Fwd: I-D 
> Action:draft-perkins-avt-rapid-rtp-sync-03.txt
> 
> Hi Thomas,
> 
> Thomas.Schierl at hhi.fraunhofer.de wrote:
> >
> > Stefan Döhla wrote:
> >> Hi Thomas,
> >>
> >> Thomas.Schierl at hhi.fraunhofer.de wrote:
> >>> 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.
> >> Let me rephrase it a little: If I accidentally receive an RTCP SR 
> >> with the same RTP timestamp as in an RTP packet in either session, 
> >> would the NTP timestamp be the same?
> > For the same RTP timestamp in SR and RTP packet, the NTP 
> timestamp in 
> > the header extension as well as in the SR shall be the same.
> Then I think my assumption was correct, that you need to 
> pre-filter the NTP timestamps so that they increase roughly 
> linearly - but at least monotonically with each according RTP 
> timestamp - otherwise it would be possible to align samples 
> from several layers but it is no more guaranteed that they 
> have the timestamps in correct order). And in addition, the 
> SRs must be filtered then as well to correspond to the 
> HDR_EXT timestamps (- what as I understood is a problem in 
> practice where NTP timestamps are often way off).
> 
> If a stream is re-timestamped by an intermediate device the 
> correspondence would be broken if not the HDR_EXT is also 
> adjusted. Also this device would have to follow the same rules.
> 
> Cheers
> - Stefan
> >
> > Thomas
> >
> >>
> >> [snip]
> >>
> 
> -- 
> Dipl.-Ing. Stefan Döhla     | Email: stefan.doehla at iis.fraunhofer.de
> Multimedia Transport        | Phone: +49 (0)9131 776 6042 (!NEW!)
> Audio Department            | Fax:   +49 (0)9131 776 6099 (!NEW!)
> Fraunhofer IIS              |
> Am Wolfmantel 33            |
> 91058 Erlangen, Germany     | Web:   http://www.iis.fraunhofer.de/amm
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>