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

From: Kristofer Sandlund <[email-masked]>
Date: Thu, 01 Apr 2004 08:43:45 +0200

[email-masked] wrote:
>>One comment is that the method that I described was something 
>>I whipped while writing that mail, since it seemed like the 
>>logical interpretation. Therefore, I described the principle 
>>of how I understood it to work than the exact method to use it. 
>>It might need some further analysis of how it can work. I'll 
>>try to look at that later this week.
> 
> 
> I thought you have been "convinced" that "there cannot be room 
> for a slope" because of this?  
> 
> It looks to me that you are now *developing* your understanding.
> Do we fall into the trap that if one can develop a different
> method than what is described in RFC 3095, then it proves that 
> slope does not exist in RFC 3095?
> 

You're taking that comment out of its context. What I intended all along with 
that was that "in the spec, as it is written today, there cannot be room for a 
slope". Sorry if I confused you. The same goes for the next comment.

> 
>>My comments are based around the assumption that "there is no 
>>slope", so I am not claiming that they are the same thing. 
> 
> 
> Sorry, have you said the following in your earlier email?
> http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg02033.html
> 
> "if we narrow this down to TS, then we get TS = SN * slope + offset.
> Compare this to the formula in 4.5.3 (quoted above), then suddenly
> it becomes clear that "slope" really means TS_STRIDE in this section."
> 

> 
>>Some testcase made some implementation set the TS_STRIDE to zero, 
> 
> 
> This is simply an incorrect implementation (see section 4.5.3).
> 
> It also demonstrated again the fundamental difference between
> slope and TS_STRIDE. The former can be zero, while the latter
> cannot.
> 

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?

BR,
	Kristofer

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

---

From: "kamal deep singh" <[email-masked]>
Date: Thu, 1 Apr 2004 12:14:01 +0200

hi Kristofer,

We can still avoid the confusion given by 2.0 if we consider that
TS_STRIDE is "expected" increase and not everytime increase.

> So, one is wrong. Which on

regards,
Kamal