[XviD-devel] B-frame "bugfix"

Radoslaw Czyz xvid-devel@xvid.org
Fri, 26 Jul 2002 01:24:38 +0930


> it's rather a "fixing the standard" than a "fixing XviD".
> Due to a stupid, stupid and once more stupid design flaw in the MPEG-4
> standard, there were bad blocks in B-frames for some contents.
> The reason is that if a macroblock is skipped in a P-frame, it isn't
> encoded in the previous B-frames either, and there is no way around
> this :-(

> To fix this, more work is needed, but I added a brute force flags

I'd like to point you (once again) to my ME code. I know that bframes
are more important than some strange rewrite of p-frame pmvfast, but
there is an interesting thing inside.

This thing is skip-decision made in motion search.
Let me explain how it works atm:
For every macroblock, I compute sads of (0,0) motion vector, both two
sad8s for chroma components and one sad16 for luma. If all values are
below a threshold (currently fixed thresh, should be quant-dependant),
block is skipped and no ME is done for it.

Now, notice how easy it is as a solution to this b-frame problem
(which is a strange idea indeed): if you are below the threshold, you
keep repeating the checks (2xsad8 + sad16) for all bframes that are
"in the way" and you decide to make SKIP only if all tests show
"green lights" - i.e. you really can skip the macroblock. One thing
that is necessary now is to make sure that block will not be skipped
unless this algorithm allows (i.e. no skip if cbp == 0 and mv == {0,0}
but ME does not allow).

What do you think? BTW, I really think that this skip-decision works
well - for example, it doesn't allow skip when pMB->iquant!=NO_CHANGE,
as skip is imposible in this case.

Radek