[XviD-devel] Rounding

[Christoph Lampert]

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. 

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).

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. 

gruel