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

From: [email-masked]
Date: Thu, 25 Mar 2004 17:58:10 -0500

Kristofer,

> For this discussion, let us limit ourselves for a possible 
> slope used by the TS field, since that's really what we are 
> discussion here and not use the "non-SN-field" term too much.

Although the question was raised due to TS, I'd like to emphasize 
that the concept of slope is not only for TS. As Kamal pointed out, 
slope is one parameter of the function (see text below from section 3.4).

   The way ROHC RTP compression operates, then, is to first establish
   functions from SN to the other fields, and then reliably communicate
   the SN.  Whenever a function from SN to another field changes, i.e.,
   the existing function gives a result which is different from the
   field in the header to be compressed, additional information is sent
   to update the parameters of that function.

> I believe that as the specis written, there cannot be room 
> for a slope that can be implicitly updated. 

Actually this is not true. We had the slope in mind when writing the RFC.
Also see below.

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

> * 5.5.1.2.  Compression logic and packets used (R-mode)
>      --non-SN-field = SN * slope + offset
> 
> I am convinced that this is just written to be general for 
> possible future profiles (with other fields than TS being sent 
> in a scaled fashion), if we narrow this down to TS, then we 
> get TS = SN * slope + offset. Compare this to the formula in
> 4.5.3 (quoted above), then suddenly it becomes 
> clear that "slope" really means TS_STRIDE in this section.

Now I can see where the confusion came from. Some clarifications:

a) No, the formula is not for future profiles. It had never been
the intension. We actually have been trying hard to reduce number of 
profiles, which may lead to interoperability issues.

b) The formula is really just an explanation of the fundamental
concept of function mentioned in previous sections.

c) The slope concept, as part of the overall FO/SO concept, came 
before the scale concept. Scaling was added later on top of the 
basic compression/decompression operation (i.e.. the function),
and it applies only to TS field.

d) As explained above and in section 4.5.3, the scaling and the
compression of scaled TS are two *separate* steps. And more important,
they are two *different* concepts, although the formula looks similar.
+ Scaling is a LOCAL concept, except the synchronization of TS_STRIDE.
+ With scaling, the compressor and decompressor still need to deal with 
the effect of packet loss/misordering on the scaled TS. 
+ TS_OFFSET is different from the offset in above formula. TS_OFFSET 
can be derived locally as by calculating TS modulo TS_STRIDE. Obviously,
it's not an independent variable (it depends on TS_STRIDE). On the contrary, 
offset has to be synchronized explicitly to the decompressor and it 
is one of the independent variables in the function from SN to
non-SN-field (offset does NOT depend on slope). 

BR,
Zhigang

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

---

From: "Pawel Szymanski" <[email-masked]>
Date: Fri, 26 Mar 2004 09:32:45 +0100

Hi Zhigang,

> 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.html%3Fidn%3D874&sid=151