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

[zhigang.c.liu at nokia.com]

Hi Abbie,

The problem is not really about the definition of "/". It becomes
a problem only because the text below attempts to deny what section 
4.5.3 of RFC3095 says clearly. That is, TS_STRIDE is a scale factor, 
not slope. It is so clear that one has to redefine "/" to work around it.

And even redefining "/" is not enough. What about the "modulo" 
operation used to calculate TS_OFFSET (see below)? Are you going to 
redefine it as well to twist the meaning of section 4.5.3?

  TS_OFFSET = (absolute value) modulo TS_STRIDE

It just doesn't hold together.

BR, Zhigang

> -----Original Message-----
> From: ext Surtees, Abigail [mailto:abigail.surtees at roke.co.uk]
> Sent: 19 January, 2005 11:14 AM
> To: Liu Zhigang.C (Nokia-NRC/Dallas); lars-erik.jonsson at ericsson.com;
> cabo at tzi.org
> Cc: West, Mark; rohc at ietf.org
> Subject: RE: TS clarification (was: [rohc] The discussion on slope(s)
> (red ux))
> 
> 
> 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
> > 
> 
> -- 
> 
> Visit our website at www.roke.co.uk
> 
> Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK.
> 
> The information contained in this e-mail and any attachments 
> is proprietary to
> Roke Manor Research Ltd and must not be passed to any third 
> party without
> permission. This communication is for information only and 
> shall not create or
> change any contractual relationship.
> 
> 

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