Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field

From: [email-masked]
Date: Fri, 26 Mar 2004 17:38:46 -0500

Hi Pawel,

Actually for robustness, the compressor must make sure that at least two ("FO") packets with TS field have been received by the decompressor before it can transit to SO state and send Type-0 packets. It will ensure that the decompressor acquires both slope and offset of the function from SN to TS. 

4.3.1.3.  Second Order (SO) State

   This is the state where compression is optimal.  The compressor
   enters the SO state when the header to be compressed is completely
   predictable given the SN (RTP Sequence Number) and the compressor is
   sufficiently confident that the decompressor has acquired all
   parameters of the functions from SN to other fields

BR,
Zhigang

> 
> Hi Zighang,
> 
> I wonder how decompressor should behave if it receives only 
> one packet with TS 
> field between two packets without TS ( for example when it 
> receives UO-0 
> packet, next UO-1-TS and next again UO-0 packet). 
> 
> I can see two options:
> 
> 1. The decompressor uses the old slope value (e.g. the one it used to 
> decompress the first UO-0 packet) to calculate timestamp for 
> the second UO-0  packet. Here we assume that single TS communicates change in 
> the offset.
> 
> 2. It calculates a new slope basing on the timestamp values 
> decompressed from  the first UO-0 packet and the UO-1 packet and next it uses 
> the new slope to calculate the timestamp for the second UO-0 packet.
> 
> Which of the above is correct ?
> 
> Regards
> 
> Pawel
> 
> > Hi Pawel,
> > 
> > Yes, your understanding is correct. It's basically the 
> geometry: two points 
> determine a line. Besides the slope, two TS values also give 
> you the offset.
> > 
> > No, RFC 3095 does not assume floating point. All 
> encoding/decoding operations 
> are integer based.
> > 
> > Zhigang
> > 
> > > -----Original Message-----
> > > From: ext Pawel Szymanski [mailto:[email-masked]]
> > > Sent: 26 March, 2004 02:33 AM
> > > To: Liu Zhigang.C (Nokia-NRC/Dallas)
> > > Cc: [email-masked]; [email-masked]; 
> > > [email-masked]; [email-masked]
> > > Subject: RE: [rohc] Slope used to compress/decompress RTP 
> > > Timestamp field
> > > 
> > > 
> > > 
> > > Hi Zhigang,
> > > 
> > > > > I base this on the following observations:
> > > > > 
> > > > > * 4.5.3. Scaled RTP Timestamp encoding
> > > > >     3. Decompression: When receiving the compressed value of 
> > > > > TS_SCALED,
> > > > >        the decompressor first derives the value of 
> the original
> > > > >        TS_SCALED.  The original RTP TS is then 
> calculated as TS =
> > > > >        TS_SCALED * TS_STRIDE + TS_OFFSET.
> > > > > 
> > > > > If there acutally was a slope, it should have been in 
> > > this formula.
> > > > 
> > > > This is a misunderstanding. Note that there are two 
> *separate* steps
> > > > involved. The formula is for the second step: deriving TS 
> > > from TS_SCALED. 
> > > > The slope plays a role in the first step: "the decompressor 
> > > first derives 
> > > > the value of the original TS_SCALED". I thought this is 
> clear from
> > > > section 4.5.3. More clarifications below.
> > > 
> > > I think that the decompressor uses slope when it receives 
> > > packets without TS 
> > > field (for example UO-0 packets). 
> > > 
> > > In this case it uses the formula to calculate new scaled 
> > > timestamp value:
> > >   
> > >    new_scaled_timestamp = old_scaled_timestamp + (new_SN - 
> > > old_SN)*slope
> > > 
> > > Next it calculates the unscaled timestamp using the 
> formula from 4.5.3
> > > 
> > > When the decompressor receives a packet with TS field, it 
> > > does not use slope. 
> > > It decompresses the new scaled timestamp value using LSB 
> > > method. Next it uses 
> > > the formula from 4.5.3 to calculate the unscaled timestamp. 
> > > 
> > > When the decompressor receives two or more packets containing 
> > > TS value in raw, 
> > > it can calculate a new slope value, for example using the formula:
> > > 
> > >   new_slope = (new_scaled_timestamp - old_scaled_timestamp) / 
> > > (new_SN - old_SN)
> > > 
> > > Am I correct ?
> > > 
> > > An additional question is whether the slope is an integer 
> > > number or could it be 
> > > a floating point number ?
> > > 
> > > Regards 
> > > 
> > > Pawel
> > > 
> > > 
> > > ----------------------------------------------------
> > > Zobacz niezwykły koncert: "Niemena Pamięci Gdański Rapsod"
> > > Największe przeboje artysty w nowych zaskakujących aranżacjach.
> > > http://klik.wp.pl/?adr=http%3A%2F%2Fmuzyka.wp.pl%2Fimprezy.htm
> > l%3Fidn%3D874&sid=151
> > 
> > 
> > 
> > _______________________________________________
> > Rohc mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/rohc
> > 
> 
> ----------------------------------------------------
> Łodzią po Wiśle - najciekawsze etiudy w Warszawie.
> http://klik.wp.pl/?adr=http%3A%2F%2Ffilm.wp.pl%2Fp%2Fwiadomosc
.html%3Fid%3D55832&sid=152

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "kamal deep singh" <[email-masked]>
Date: Sat, 27 Mar 2004 16:22:49 +0100

Hi,

I have one question below.

> Actually for robustness, the compressor must make sure that at least two
("FO") packets with TS >field have been received by the decompressor before
it can transit to SO state and send Type-0 >packets. It will ensure that the
decompressor acquires both slope and offset of the function from >SN to TS.

In U and O mode, how will compressor base its confidence?
By sending L + 1 or 2L packets?

Or should it be left as an implementation choice?

regards,
Kamal