RE: TS clarification (was: [rohc] The discussion on slope(s) (red ux))

["Surtees, Abigail" <abigail.surtees at roke.co.uk>]

Hi All,

How about rephrasing the final paragraph to:

"In the compression step explained following this core equality of
   section 4.5.3, TS_SCALED is written as TS / TS_STRIDE.
   This formula assumes (as in the rest of the RFC) that "/"  means 
   "the integral part of the result from dividing X by Y", however, 
   this is clearly undefined if TS_STRIDE has a value of 0.  As the
   core equality above does not prevent setting TS_STRIDE to 0 
   (leaving TS = TS_OFFSET), and there is no reason not to allow a 
   compressor to do that, the formula of "2. Compression" should be 
   seen as a possible way for RoHC instances to calculate TS_SCALED 
   and TS_OFFSET, however, it is not to be used if TS_STRIDE = 0."
?

I agree that "/" is generally accepted to mean "the integral part of the
result from dividing X by Y" so we shouldn't write text that implies this
might not be the case.

Best regards,

Abbie
> 
> 
> I'm amazed. I haven't seen a "clarification" that has so many 
> logic holes in it. I may be alone on this (it seems so at 
> this moment),
> but it in worst case will break RFC 3095, and at the best will make 
> text of RFC 3095 inconsistent. 
> 
> Just a few examples below.
> 
> > > TS_SCALED is incorrectly written 
> > > as TS / TS_STRIDE. This formula is incorrect both because it 
> > > excludes TS_OFFSET, 
> 
> No, it does NOT. Did anyone read the following text from section 
> 4.5.3 in RFC 3095? Or it simply doesn't matter, as people can now 
> freely change RFC 3095 in whichever way they like?
> 
>    1. Initialization: The compressor sends to the 
> decompressor the value
>       of TS_STRIDE and the absolute value of one or several TS fields.
>       The latter are used by the decompressor to initialize 
> TS_OFFSET to
>       (absolute value) modulo TS_STRIDE.
> 
> > > and because it would prevent a TS_STRIDE value of 0. 
> 
> That's how it is intended to be. TS_STRIDE is a scale factor, 
> not slope.
> Therefore, it is supposed to be non-zero.
> 
> Isn't that obvious from section 4.5.3???
> 
> > If "/" were a generally unambiguously defined operation meaning "the
> > integral part of the result from dividing X by Y", 
> 
> That *is* the meaning of "/". Otherwise, what else could it mean here?
> Or in the following appearances throughout RFC 3095? Are all of them
> going be to be called "ambiguous" as well?
> 
> Section 4.5.3:
> - the TS will increase by n * 3000 (= n * 90000 / 30) between 
> video frames.
> - 0xFFFFFFFF / TS_STRIDE
> 
> Section 4.5.4:
> - (a_n - a_j) / TIME_STRIDE
> - T_approx = T_ref + (a_n - a_ref) / TIME_STRIDE
> 
> (Section 4.5.4 even goes extra mile to note: "Integer 
> arithmetic is used in all 
> equations above." Now it seems this should also be put in 
> section 4.5.3. Well,
> I don't believe even that can prevent the twisting of words ...)
> 
> Section 5.7.6.8:
> - (a_i - a_j) / TIME_STRIDE
> 
> > the absence of TS_OFFSET could be explained, 
> 
> What absence??? Isn't the TS_OFFSET clearly specified (see above)?
> 
> BR, Zhigang
> 

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