[XviD-devel] Rounding

Michael Militzer xvid-devel@xvid.org
Wed, 30 Oct 2002 15:00:16 +0100


Hi,

----- Original Message -----
From: "Christoph Lampert" <chl@math.uni-bonn.de>
To: <xvid-devel@xvid.org>
Sent: Wednesday, October 30, 2002 2:00 PM
Subject: Re: [XviD-devel] Rounding


> On 30 Oct 2002, skal wrote:
>
> > OMG, this rounding is such a mess :)
> >
> > I've re-read the infamous section  7.6.5 and
> > here are some things I noticed:
> >
> > a) "...in quarter pixel mode the vectors are divided
> >          by 2 *BEFORE* summation"
>
> Yes, but they are _not_ rounded! This is a very badly written part of the
> standard, but dividing by 2 doesn't mean rounding unless they explicitely
> say so. If a qpel-value of 5 is divided by 2, it 2.5 afterwards! Yes,
> fractional value for halfpel positions are possible, until the rounding
> is really done (using 7-6 to 7-9):

no, forget about fractional values!!

> "Section 7.6.3 General motion vector decoding process
>
> ... Please note that if the quarter smaple mode is enabled..., the
> resulting motion vectors are still given in halfpel units which absolute
> values need then however no longer be integer."

this part is not valid anymore (look up your new docs ;-)). The idea was to
represent ALL qpel values as fractional numbers, but this has been dropped
and also qpel values are stored as integers now (have a look at ms-fdam code
for example...). - I know, again very confusing...

> > mv_x = DIV2RND(mv[0].x) + DIV2RND(mv[1].x) + DIV2RND(mv[2].x) +
DIV2RND(mv[3].x);
> > mv_y = DIV2RND(mv[0].y) + DIV2RND(mv[1].y) + DIV2RND(mv[2].y) +
DIV2RND(mv[3].y);
> >
> > and then proceed with table table 7-6...
> > I think it's really a two-step process (qpel->halfpel), probably
> > mergable into a single one...
>
> No, I really don't think so.
>
> >         b) This section always mention "dividing" ("by 2K", "by 2", ...)
> > But it's not clearly stated which division it is (/? //? ///?).
>
> floating point!

no floating point !!

> > The only place where I see the exact operator is in the
> > legend of table 7-6 -> 7.9. It seems to be // (nearest integer,
> > rounding away from 0). Hence the DIV2RND(x) ... Might
> > other  implementors fail to use this one too?
>
> I don't interpret this a division '//' but as some kind of 'commentary'
> for the resolution:
> "file://16 means 16th-pel resolution", "file://2 means "halfpel" etc.

exactly

> > c) Maybe a bad news: at the beginning of clause, we have:
> > "A I macroblock comprises either one MV or K motion vectors,
> > one for each non-transp 8x8 pel blocks forming the 16x16
> > pel macroblock, as is INDICATED BY THE CBPC CODE" !!
> > Would it mean that K is not always 4 when CPBC!=0xf??
> > Hope not...
>
> I read "as INDICATED BY THE MCBPC CODE." and mcbpc contains information
> about what type a macro block is (including the decision inter or
> inter4v). And it contains the information if there are DCT ceofficients
> for chroma, but _not_ if there are DCT for lumi!
>
> I guess "transparent" is only for arbitrarily shapep objects, not for
> rectangular ones.
>
> I'll ask about all this at mpep4-technotes...

no bad idea...

bye,
Michael