[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: TS clarification (was: [rohc] The discussion on slope(s) (red ux))
Folks,
Let me make a few observations related to the "/" discussion:
1) In 3095, "/" is used for integral division ONLY for TS scaling,
so it is plain wrong(tm) to claim that it is generally used in
this way in 3095.
2) In general, I strongly disagree that "/" is normally used for
integral division. In all sophisticated programming languages,
integral division has its own operands, while "/" is the operand
generating a decimal result. "mod" is often defined to generate
the reminder from integral division, while an operand with names
such as "div", "floor", etc are defined and used for the integral
division itself. None of these can be claimed to be generally
accepted and understood, but point being that integral division
is special and usually handled with care. In this case, it had
of course been enough if section 4.5.3 had made clear what was
meant.
3) Even assuming "/" means the integral part of the division result,
the formula in "2." can only be used to calculate TS_SCALED, not
TS_OFFSET.
I therefore question this reformulation, as I do not see what is
actually wrong with the previous text. I could accept the suggested
text if we removed "(as in the rest of the RFC)", as well as "and TS_OFFSET" (due to reasons above), but still I can not see what
would be the point of changing what is currently there.
BR
/L-E
> -----Original Message-----
> From: Surtees, Abigail [mailto:abigail.surtees at roke.co.uk]
> Sent: den 19 januari 2005 18:14
> To: 'zhigang.c.liu at nokia.com'; Lars-Erik Jonsson (LU/EAB);
> 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