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

From: [email-masked]
Date: Thu, 2 Dec 2004 15:54:23 -0500

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 2 Dec 2004 22:26:14 +0100

> downscaled before compression. Obviously, it cannot be 0 (zero).

Well, zero is not exactly prohibited, but then you couldn't send any 
other value than TS_OFFSET, which wouldn't be too useful.

> synchronize TS_STRIDE between the compressor and decompressor.

I hope we are all in agreement about this.

> its slope and offset) is from SN to the TS_SCALED.

This is the msg934 dynamic slope.

In 3095, some of this shines through in the description of R-mode, but 
in no other place.

I believe we are split between:
-- This is a mistake in the R-mode text
-- msg934 slopes only apply to R-mode (one quite logical conclusion 
from the text of 3095)
-- msg934 slopes apply to all headers that do not send a timestamp.

In the latter two cases some text from msg934 or equivalent would need 
to be retrofitted to the standard.

> original TS to TS_SCALED; and 2) compression of TS_SCALED.

Again, I hope we all agree on this part.

> offset      <-------- (-10)-------->    <----- (39) ---->

The problem with this picture is that it does not identify which of the 
packets are context-updating.
The way I read msg934, the intention of this proposal was to only 
compute slope from the points created by CRC-checked packets.

> field(X) have been correctly decompressed.

I'm not sure I understand this sentence.

After SN-60 and SN-61 (assuming both are context-updating), the msg934 
slope is 50.
(If SN-60 is not context-updating and SN-59 and SN-61 are 
context-updating, the slope is 25.
If neither SN-59 nor SN-60 is context-updating and SN-58 and SN-61 are 
context-updating, there is no msg934 slope and you cannot send -0 
headers if you assume msg934.)
Since you don't really know which of these actually arrived (even in 
R-mode, you must wait for the ACKs to arrive, and some these might even 
be lost), it will take a while before it is one again.
This is one of the reasons I'm not a great fan of msg934 slopes.

Gruesse, Carsten