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

> http://www1.ietf.org/mail-archive/web/rohc/current/msg02081.html
> (the last one included questions to Zhigang, which were ignored)

Kristofer,

Lars-Erik pointed out that I didn't reply to your questions
(copied below) in the above email. Sorry about that. I probably 
missed them. Handing that many emails were not easy for me.

Short answers: section 4.5.3 is correct. The definition of
TS_STRIDE in section 2 is wrong.

Long answers. ROHC works at RTP packet level. That's for sure.
What section 4.5.3 says is that for video, you can still
scale the TS by TS_STRIDE (see example below). The mentioning 
of "frame delta" is to explain why and give reminder about
the special "ladder" characteristics of TS in video.

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

RE the definition of TS_STRIDE, it was probably written
with audio context - the most important application of
ROHC. But it's not generic enough to cover video.

Another note: TS scaling is optional. Of course, scaling 
by a factor of 1 is equivalent to no scaling.

BR, Zhigang

--------------------------------------------------------------------
Ok, now I see one reason that we both base ourselves on the spec but reach opposite conclusions.
This example in 4.5.3 actually explains your thinking:

In the case of video, there is usually a TS_STRIDE as well when the
video frame level is considered. The sample rate for most video
codecs is 90 kHz. If the video frame rate is fixed, say, to 30
frames/second, the TS will increase by n * 3000 (= n * 90000 / 30)
between video frames. Note that a video frame is often divided into
several RTP packets to increase robustness against packet loss. In
this case several RTP packets will carry the same TS.

That is a contradiction of 2.0:

Timestamp stride

The timestamp stride (TS_STRIDE) is the expected increase in the
timestamp value between two RTP packets with consecutive sequence
numbers.

4.5.3 talks about stride as the "frame delta" and 2.0 as the "packet delta".
So yes, if 4.5.3 "overrides" 2.0 then you're right that the stride cannot be 0, and then I can see why you think I'm silly to say we must define modulus 0. But if 2.0 overriders 4.5.3, then I still think I'm right.
That's one quite fundamental difference.

So, one is wrong. Which one?
-----------------------------------------------------------------

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc