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

From: [email-masked]
Date: Wed, 7 Apr 2004 17:59:45 -0400

Hi Vick,

Please see my answers below. I hope they help, but feel free to 
ask more questions.

BR,
Zhigang

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

It follows the basic mathematics that two points determine a line. 
The decompressor needs to receive two packets in order to 
determine the linear function from SN to TS_SCALED:

    TS_SCALED = SN * slope + offset

Let's assume that in example 2, the decompressor receives packet
11 and 12 that carry scaled TS info. Here is what happens:

Step 1: decompress TS_SCALED according to W-LSB or timer-based
compression (if enabled). It will derive TS_SCALED = 1 for
both packet 11 and 12.

Step 2: calculate the slope
slope = (TS_SCALED_2 - TS_SCALED_1) / (SN_2 - SN_1)
      = (1 - 1) / (12 - 11) 
      = 0

Step 3: calculate the offset
offset = TS_SCALED_1 - SN_1 * slope
       = 1 - 11 * 0
       = 1

Step 4: derive the unscaled TS according to section 4.5.3.
 
> b. what are slope & offset between pkts 60/61 and 25/26?

Following the formula above, (slope, offset) = (50, -2950)
and (1, -24), respectively. Of course, they are transient
and of no use.

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

The question should actually be: why do we need scale? Please note
that slope and offset are the fundamentals for compression. That's
also why we used the word "First-Order" and "Second-Order". We only 
added scale *later* as an enhancement. (Please refer to my earlier 
emails explaining this.)

Now, do we need both? The answer is yes. Besides the clear difference
between the two in concept, here are some practical examples:

- In example 2, the compressor can establish TS_STRIDE = 3000 and
keep it that way. That save bits during FO state (compressing 1,
2, ..., instead of 4000, 7000, ...). At the same time, 
(slope, offset) are used for SO state. This is cleaner and more
efficient than changing TS_STRIDE as described in this email
thread, which also conflicts with section 4.5.3.

- In another example (I think I've mentioned this already), some
application may change packetization characteristics in reaction
to underneath transport conditions. For example, it may encapsulate
1 audio frames in one RTP packet for sometime and 2 frames per 
packet for other period of time. In that scenario, the compressor 
can establish TS_STRIDE corresponding to one audio frame (e.g. 160)
for once, and then use different slope (e.g. 1 or 2) to cope with 
the change of packetization. 

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

---

From: "Pawel Szymanski" <[email-masked]>
Date: Thu, 8 Apr 2004 09:12:22 +0200

Hi,

> the change of packetization. 

Yet another example of using both TS_STRIDE and slope is AMR codec (widely used 
in 3GPP). Normally the codec generates frames every 20 ms. But during silence  
periods, special frames (so called SIDs) are generated every 8*20 ms.

In my example TS_STRIDE is once at the beginning of the phone call and is equal 
to 20 ms. While slope is changing during the call. Nomrally the slope is equal 
to 1, but during silence periods it is equal to 8.

Pawel

----------------------------------------------------
Przegląd Piosenki Aktorskiej "Artyści Europy". 
Wrocław 23.04 - 2.05.2004 r. Gwiazdy, spektakle, recitale, koncerty
specjalne! http://klik.wp.pl/?adr=http%3A%2F%2Fwww.ppa.art.pl%2Fsub-ppa.php%3Fpid%3D65&sid=158