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

From: [email-masked]
Date: Fri, 2 Apr 2004 19:27:48 -0500

Lars-Erik,

Please see comments below.

BR,
Zhigang

> On the other hand, why should it not be possible to have a scaling
> FACTOR of 0. 

Because that is not what section 4.5.3 says.
 
> to me the video example
> seems to be a reasonable argument for enforcing the TS_STRIDE
> definition from section 2, and thus allow it to be 0.

Why did you say the video example is an argument for enforcing
the TS_STRIDE definition in section 2? Could you please elaborate?

> This proposal still does not address the original concern about
> the concept of slopes not at all being defined in 3095. That is
> the major issue here, I think.

OK. If the meaning of slope is not obvious to you, why don't we 
have a clarification as follows? I also added other clarifications
to address other confusions I've seen so far. Now I'm risk of 
being too verbose, but it seems the only way to avoid confusion. 
Comments?

------------------------------------------------------------
As it is described in section 4.5.3 and other places in RFC
3095, TS_STRIDE is the factor by which an RTP Timestamp is
downscaled before compression. Obviously, it cannot be 0 (zero).

The wording of TS_STRIDE definition in section 2 is confusing
and may be incorrectly interpreted as TS_STRIDE is always equal
to the increase in TS value between two RTP packets with
consecutive sequence number. This is not the intent of the
specification. It is the compressor that decides whether TS 
scaling should be used and if yes, what is the best value of 
TS_STRIDE. See section 4.5.3 for information. How this is done 
is an implementation issue. However, an implementation must follow 
section 4.5.3, 4.5.6 and 5.7 on how to initialize, encode, and 
synchronize TS_STRIDE between the compressor and decompressor.

Note: TS_STRIDE is not the same as slope described in section 
5.5.1.2 and 5.7. Here, slope has the general meaning in mathematics.
Namely, slope(X) equals the change of a non-SN field X between
two packets divided by the change of SN field between the same
two packets. It is one of the two parameters (the other one
being offset) that define a linear function from SN to field X.
The concept can also be visualized as a line, with SN being
the horizontal coordinate and the field X being the vertical 
coordinate. For TS, this applies regardless whether it is scaled 
or not. In case the TS is scaled, the linear function (or equivalently
its slope and offset) is from SN to the TS_SCALED.

Note: it should be clear from section 4.5.3 that when scale is
used for TS, two steps are involved: 1) downscale of the 
original TS to TS_SCALED; and 2) compression of TS_SCALED.
The decompressor follows the reverse procedure with two steps.
Following are two examples to further illustrate this.

Example 1 (audio stream with TS_STRIDE = 160):

            <------ String 1 ------>    <-- String 2 --->
SN           11  12  13  14 ...   60    61    62    63 ...
TS          200 360 420 580 ... 8040 16040 16200 16360 ... 
TS_SCALED     1   2   3   4 ...   50   100   101   102 ...
TS_OFFSET    40  40  40  40       40    40    40    40 ...
slope       <--------  1 ---------->    <----- 1 ------->
offset      <-------- (-10)-------->    <----- (39) ---->

Example 2 (video stream with TS_STRIDE = 3000):

            <------ String 1 ------>  <-- String 2 --->
SN            11   12   13 ...    25   26   27   28 ...
TS          4000 4000 4000 ...  4000 7000 7000 7000 ... 
TS_SCALED      1    1    1 ...     1    2    2    2 ...
TS_OFFSET   1000 1000 1000 ...  1000 1000 1000 1000 ... 
slope       <--------  0 ---------->  <----- 0 ------->
offset      <--------- 1 ---------->  <----- 2 ------->

Note: the default-slope(X) specified in section 5.7 is to be used 
by the compressor and decompressor to initialize the slope of the 
linear function from SN to field X. This is an optimization to 
save synchronization overhead at the beginning of an RTP packet 
stream. Namely, if the actual slope of X in the first string matches 
the default-slope(X), the compressor can enter SO state and send 
Type 0 packets once it is confident that one - instead of two in 
the normal case - packet carrying field(X) has been correctly 
decompressed by the decompressor. This is enough for the decompressor
to determine the other parameter, i.e. offset, for the linear function
from SN to X. After the fist string, the decompressor will update the
linear function from SN to X depending on how many packets carrying
field(X) have been correctly decompressed. If the number is 1,
the decompressor will assume the new slope(X) = previously established
slope(X), and the update offset(X) based on field(X) received. If the 
number is 2, the decompressor will update both slope(X) and offset(X).
Note that the decompressor always uses the latest received packet(s)
to update the function.

For instance, in Example 1 above, the compressor can enter SO state once
it is confident that one packet carrying TS has been correctly decompressed 
by the decompressor. This is because the actual slope of TS (after scaling)
equals the default-slope. Of course, the TS_STRIDE = 3000 must be 
synchronized also, which can be done within the same packet. 

Example 2 is different. The actual slope (= 0) of scaled TS does not equal
the default-slope (= 1). Therefore, during the first string of the packet 
stream, the compressor has to ensure that two packets carrying TS info
have been correctly decompressed by the decompressor. This allows the
decompressor to establish both the slope and offset for function from
SN to scaled TS. However, for subsequent strings, only one correctly
decompressed packet is needed since slope = 0 has already been established
and thus can be reused.
--------------------------------------------------------------------

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

---

From: Vicknesan Ayadurai <[email-masked]>
Date: Wed, 7 Apr 2004 20:46:32 +0200 (CEST)

Hi Zhigang,

Thanks for providing the examples at the end of your mail below - this
is definitely helpful to illustrate the problem (to me anyway).

> offset      <--------- 1 ---------->  <----- 2 ------->

What's a little un-clear is:

a. how "offset" is computed above (esp for Ex2)?

b. what are slope & offset between pkts 60/61 and 25/26?

Finally, as I mentioned before, the RFC states that:

--<START snip RFC3095 pg 29>--
   ...
   ...
   bits for each compressed TS.  TS and TS_SCALED satisfy the
   following  equality:

      TS = TS_SCALED * TS_STRIDE + TS_OFFSET

   TS_STRIDE is explicitly, and TS_OFFSET implicitly, communicated to
   the decompressor.  The following algorithm is used:
   ...
   ...

--<STOP snip RFC3095 pg 29>--

c. Since, as you noted in your examples, TS_SCALED, TS_STRIDE and
TS_OFFSET are obtainable and subsequently, plugging them into the
equation above should give TS. Hence, is there any particular reason
why "slope" or "offset" is needed...?

Regards,
vick