[XviD-devel] qpel - problems I found

Michael Militzer xvid-devel@xvid.org
Sat, 12 Oct 2002 15:34:30 +0200


Hi,

thanks for your notes, Radek. It's been very helpful...

> First: decoding of qpel frames fails on other decoders. We all know
> that, and I've found a reason.
> This is because when you do motion compensation for chroma, there is:
>
>          dx = (dx >> 1) | (dx & 1);
>          dy = (dy >> 1) | (dy & 1);
>
> Well, if I remember correctly doing dx >>1 on a potenetialy negative
> value doesn't work as it should - am I right? (not a rethorical
> question, I'm not sure).

I'm not sure, too. Are zeroes or the sign bit shifted in?

> Anyway, changing it to
>         dx = dx/2;
>         dy = dy/2;
> fixed the problem on all decoders, and also decreased filesize. Same
> thing exist in decoder.

I don't think that this is correct either. The standard says that qpel
vectors are not simply halfed but rounded to the next halfpel value using
this table:

fourth pixel position    0    1    2    3
resulting position        0    1    1    1

so:
    dx = (dx / 2) | (dx & 1);
    dy = (dy / 2) | (dy & 1);

should be ok then...

> Second:
> Right before qpel refine, SADs consist of 'real' SAD and d_mv_bits,
> where d_mv_bits is the vector weight *for halfpel conditons*. When you
> do qpel refinement, you compare it against 'real' sad + d_mv_bits(qpel
> conditions). As d_mv_bits[qpel] is statistically twice as big, there
> is a big possibility that comparsion is not fair and some vectors
> (qpel refinement vectors) have worse chances.

ouch, of course. While I tried not to change the normal halfpel search
behaviour and add qpel as an extension to the ME, I totally forgot about
this. Thanks you pointed that out...

> I've made a fix - or rather a hack. I substract d_mv_bits[hpel] and
> add d_mv_bits[qpel] before qpel refinement.
>
> It's a bit more complicated with 8x8 search - I have to substract
> mv_bits[qpel] and add mv_bits[hpel] at the beginning. Then, I do
> halfpel search and move to qpel again and do qpel refinement....
>
> I'm sure there is a better way for all of this (like using
> d_mv_bits[qpel] from the beginning) but I won't fix it until the code
> settles more.
>
> There is a reasonable filesize gain after this fix.

no surprise - *blush*

> Third:
> While doing "normal" search maximum vector ranges are different. This
> has been taken into account by decreasing fcode by 1 which is quite
> smart.
> However, when you move to qpel refinement there is no other way but
> re-calculate "real" maximum range, and this has been forgotten.
> The filesize/psnr gain from this fix is also.. well not big but
> measurable.

again ouch - This has been lost while I replaced my huge qpel refine
function by a nice small one + dedicated CheckCandidate functions (it's
really incredible how I managed to get that much bugs into the code...)

> Now, a question: what happened to hinted ME? second pass crashes,
> even for normal halfpel.

hm, I didn't touch it at all.

> Now, a suggestion: checking of qpel vectors consists of: making average
> of two pictures and computing SAD between this average and reference.
> This is ok, but tell me: how is it different then doing sad8bi from
> the beginning? Of course sad8bi doesn't have rounding value but it
> shouldn't be a problem.
> Doing it this way seems to be the fastest.

yes, this was planned. I talked about it with Christoph already weeks ago,
but then I didn't had the time to write the new sadbi functions yet. But
it's true, refinement should be faster then. The sadbi functions could also
be used for block-based refinement in normal halfpel mode. I'm very sure
that at least lower quality modes without 4MV search/refinement would be
faster block-based...

bye,
Michael