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

[Carsten Bormann <[e-mail]>]

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

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

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

I hope we are all in agreement about this.

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

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.

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

Again, I hope we all agree on this part.

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

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.

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

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


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