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

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

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