RE: [rohc] The discussion on slope(s)

[[e-mail]]

Hello Folks,

As Lars-Erik asked, below is the clarification text I proposed
back in April, based on my own interpretation of text in 3095 
written by myself. I also included some examples to show exactly 
how encoding/decoding works. Those were actually discussed
when we developed 3095. But it's good to give them again to
show enough technical details.

Again, the clarification may be too verbose. My intention is to 
make it as clear as possible.

As always, comments and questions are welcome.

Br, Zhigang

------------------------------------------------------------
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/rohc