[XviD-devel] Rounding

Michael Militzer xvid-devel@xvid.org
Wed, 30 Oct 2002 14:32:22 +0100


Hi,

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


> On Tue, 29 Oct 2002, Michael Militzer wrote:
> >
> > ok. sorry, it seems it was not clear that this was not my code but just
an
> > excerpt from an earlier discussion between you (Christoph) and Skal.
I've
> > shortened the code part, but maybe this was no good idea, so here's the
> > (whole) original mail again:
> >
> > [...]
> >
> > The problem was not (only) INTER4V related (which means 16th pel ->
> > halfpel), but ms-fdam didn't even correctly decode XVID qpel content
without
> > 4MV mode. So far I did two rounding steps (each from
quarterpel->halfpel) in
> > motion compensation (one for the rounding from qpel vectors to halfpel
> > vectors, and one to match the lower resolution of the subsampled u,v
> > planes). It seemed correct this way since the standard explicitely says
that
> > the halfpel u,v vectors should be calculated using table 7-9 (see
subclause
> > 7.6.2.2) and all following steps should be performed as in normal
halfpel
> > mode then. Obviously ms-fdam does the rounding in one step using table
7-8
> > (which is not at all a stupid idea btw) and after I modified XVID to
> > consider this our chroma problems were gone. So I'd say the way ms-fdam
> > handles chroma compensation is correct, but the description in the
standard
> > is misleading then imho...
>
> I read this part as follows:
>
> Do "rounding to halfpel position" (Table 7-9) and then
> calculate halfpel values as in section 7.6.2.1 (which is the description
> of how to calculate halfpel, without any mirroring etc.).
> For non-inter4v this is true, because no additional rounding step is
> described in 7.6.2.1. The whole section does not speak about inter4v,
> it start with some remark that it's applied to 16x16 or 16x8 blocks.

yes, I read it that way too. However if you use Table 7-9, it's wrong... :-(

In normal halfpel mode, the chroma vector is calculated buy rounding down
the luma motion vector using table 7-9 (to match the lower resolution of the
subsampled u,v planes). The standard says that table 7-9 should we used in
qpel mode to round the qpel vectors -> halfpel resoultion and then one
should be proceed as in halfpel mode So this would mean: step 1: use table
7-9 and round luma qpel vector to halfpel precision, step 2: use table 7-9
again and round halfpel luma vector to halfpel chroma vector. FDAM does this
in one step using table 7-8...

> Later, just before the Tables 7-6 to 7-9 is a remark about chroma with
> inter4v (K=4):
> "Motion vector MVD_CHR for both chrominance blocks is derived by
> calculating the sum of the K luminance blocks ... divide by 2*K ...
> The component values of the resultung 16th/12th/8th/4th sample resolution
> vectors are modified towards the nearest half sample position as indicated
> below"
> (and then there are the tables).

that's exactly the problem I talked about: One should think that having only
1MV, the chrominance MV is calculated using table 7-9 (and following
subclause 7.6.2.2 this should be true regardless if we're in half- or
quarter sample mode...)

> I guess the whole stuff is very misleading, maybe it has been corrected
> in the final version.
> But the ms fdam implementation (and ours, now) is the intended one. If it
> works, let's stick to it.

yes

bye,
Michael