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

[Stefan Döhla <stefan.doehla at iis.fraunhofer.de>]

Hi Ye-Kui,

Ye-Kui Wang wrote:
>  
> 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 
>
>   

The example would be related to the bad behaviour of some 
implementations that create quite rough RTCP SRs when it comes to 
timestamp creation. I think Asterisk was a good example of NTP 
timestamps that jump back and forth. If the same bad clock would be used 
to write the NTP timestamp for the HDR_EXT, then you would end up with 
subsequent packets where the RTP timestamp is e.g. monotonically 
increasing but the NTP timestamp is not because there's a high jitter added.

I don't say the HDR_EXT is bad per se (it has other advantages, see the 
ISMA paper) but it would be good if a little more restrictions can be 
put on the sender to ensure that the NTP and RTP timestamps are well 
correlated - though as I said before, this would not break the ability 
of the solution to find the layers for a single point in time.

Cheers
- Stefan
> > -----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