[XviD-devel] dark blocks in b-frames

[Christoph Lampert]

On Sat, 15 Feb 2003, Radek Czyz wrote:
> Anyways, in light of my previous mail - I think we'll have to detect
> this kind of blocks and 'fix' them, simply because they look horrible.
> 
> > as gruel has said, this probably isnt a bug, rather the effect of using
> > a mix or high quantizers for bframes.

I see two possibilities for this: 
 
a) Quick and dirty: Don't allow sum==1 blocks in B-VOPs (just as in
P/I). Make them 0. 
This might give even bigger artefacts, if 1 was right! So better only 
don't allow those sum==1 blocks where rounding is done "in the wrong
direction". This is simple to do, but not simple to do well. 

b) Better: Add a flag "FLICKERING_BLOCKS_WORKAROUND". Detect blocks with
sum==1 and encode them with lower quant. Every non-direct B-block has 
a "dbquant" field which codes a quant difference of +2,0,-2 (Table 6-28).
A "flicker candidate" MB would have to be coded FORWARD/BACKWARD or 
INTERPOLATE with dbquant==-2. The next block in line would have to
FORWARD/BACKWARD/INTERPOLATE coded with dbquant==+2. Both blocks could not
be MODE_DIRECT. 
So this might cost a few bits (2 extra for quant change in 2 blocks, 
2 extra for INTERPOL instead of DIRECT in 2 blocks, some bits because 4
instead of 2 or 0 MVs are encoded). Only if collocated block is INTER4V
or in QPel mode this will not give exactly the same result as DIRECT, but 
I doubt the difference will be noticable (except for less flickering). 


> I wonder why noone noticed this in DivX5. They should also have the
> problem, especially because they use even higher quantizers for
> bframes.

Simple: Decode DivX5 and search for  DCT==-1 sum==1 / DCT==1, sum==1
blocks. Maybe they do some filtering, too.

gruel