[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: TS clarification (was: [rohc] The discussion on slope(s) (red ux))
Hi Lars-Erik, all,
Happy New Year! Apologies for the delay. Mark and I agree with the text
proposed. We've word-smithed it a bit below to make some of the sentences
clearer. One other comment:
- use default-slope instead of default_slope to be consistent with RFC 3095
(we've changed as many as we spotted :-))
Best regards,
Abbie
4.2. (De)compression of TS without transmitted TS bits
RFC 3095 explains that SO-state provides the most efficient compression
within ROHC RTP. In this state, apart from packet type identification and
the error detection CRC, RTP compressed headers carry only RTP sequence
number (SN) bits.
All other fields are then omitted either because they are unchanged or
because they can be reconstructed through a function from the SN (i.e. by
combining the transmitted SN bits with state information from the context).
> Although it is
> never spelled out explicitly what fields are inferred from
> the SN in this way, one should be able to figure out that
> this principle applies to the IP Identification (IP-ID) field
> and the RTP Timestamp (TS) field.
>
IP-ID compression and decompression, both with and without transmitted IP-ID
bits in the compressed header, are well defined in section 4.5.5 (see
section 8.2 of this document).
> However, for TS it is only defined how to
> decompress based on actual TS bits in the compressed header,
> either scaled or unscaled, but not how to infer the TS from
> the SN, i.e. the SO-state operation. Although the general
> idea is simple, the actual operation must be clearly defined
> to ensure interoperability. There are also inconsistent text
> pieces that might confuse an implementer and result in
> non-interoperable implementations. This section therefore
> provides the necessary clarifications to SN-to-TS
> decompression, i.e. decompression of TS (scaled or unscaled)
> when no TS bits are transmitted in the compressed header.
>
> When no TS bits are transmitted in the compressed header, the
> encoded TS value (scaled or unscaled) is to be decompressed
> assuming a linear extrapolation from the SN, i.e. delta_TS =
> delta_SN * default-slope.
>
> Section 5.7 defines the potential values for default-slope as:
>
> If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before
> compression (see section 4.5.3), and default-slope(TS) = 1.
>
> If value(Tsc) = 0, the Timestamp value is compressed as-is, and
> default-slope(TS) = value(TS_STRIDE).
>
What must be noted here is that no slope value is used other than the
default-slope value, as defined in section 5.7.
> There is confusing text in
> section 5.5.1.2 that might mistakenly be interpreted as if
> the slope can have different values and be "learned", which
> is incorrect. The default-slope from 5.7 is always the value
> used when decompressing TS based on SN.
>
>
> 4.4. TS_STRIDE for scaled timestamp encoding
>
> The timestamp stride (TS_STRIDE) is defined as the expected
> increase in the timestamp value between two RTP packets with
> consecutive sequence numbers. TS_STRIDE is set by the
> compressor and explicitly communicated to the decompressor,
> and it is used either as the scaling factor for scaled TS
> encoding, or constitutes the default-slope used when
> decompressing an unscaled TS through a linear extrapolation
> from the SN (see also section 4.2 above).
>
> The relation between TS and TS_SCALED, given by the following
> equality in section 4.5.3, defines the mathematical meaning
> of TS_STRIDE:
>
> TS = TS_SCALED * TS_STRIDE + TS_OFFSET
>
> In the compression step explained following this core
> equality of section 4.5.3, TS_SCALED is incorrectly written
> as TS / TS_STRIDE. This formula is incorrect both because it
> excludes TS_OFFSET, and because it would prevent a TS_STRIDE
> value of 0.
If "/" were a generally unambiguously defined operation meaning "the
integral part of the result from dividing X by Y", the absence of TS_OFFSET
could be explained, but the formula still lacks a proper output for
TS_STRIDE equal to 0. As the core equality above does not prevent setting
TS_STRIDE to 0, and there is no reason not to allow a compressor to do that,
the formula of "2. Compression" should not be read as having any formal
meaning.
_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc