[XviD-devel] dark blocks in b-frames. some resonable answers, finally

[Christoph Lampert]

Hi,

somehow the topic is solved, but here is my final idea for a quick
"solution": 

>From what Radek checked we know that bframes have a bias towards
"overcompansation" due to rounding. 

I'm not sure about forward and backward mode: I thought there we use the
(possibly halfpel interpolate) reference picture which is does with
ordinary rounding==0 or rounding==1. I don't know where extra rounding
come into play. Let forget about those for the moment.  

For interpolated and direct mode, B-frames routine surely has to
interpolate. This is always done with rounding==0, because the standard
demands it (that's faster for hardware implementation, I guess). 

So we know, that every stop of interpolation will round up in 2 of 4
cases, and never round down. 

r1&1  r2&1    "real"    rounded (r1+r2+1)/2 
 0     0        0            0
 0     1       0.5           1
 1     0       0.5           1
 1     1        1            1

The expectation value of error is 0.25 instead of 0.00 in a perfect world,
so we know that in the mean, block luminance will be too high by
0.25. This cannot be expressed in the image domain, of course. But it
_can_ in the DCT domain, because DC coefficient has higher resolution
than [0,255]. 
So let's simply subtract the (constant) value of DCT(0.25) from the DC
coefficient before quantization and see what happens. In theory, there
should then be as many "too dark" blocks as there are "too light" blocks,
but fewer than there are now. 

If the light blocks are less visisble, we can change the bias to more than
DCT(0.25). Remember: We can do anything we want with B-frames, it doesn't
change coding efficiency, since they are not used for prediction. 

I'm not completely familiar with rounding in bframes. Radek wrote that 
for forward and backward mode we are rounding as well, and for
interpolated and direct mode even twice. 
Then of course, we would have to change the value, and use it for forward
mode, too. We could also take into account, that we _know_ if a vector has
even or odd components, so we know if it acts on an interpolate image or
not. This could play a role as well. 

Maybe somebody can check, if rounding in QPel is somewhat the same, or
even more biased.

gruel

P.S. Another way would be to not do rounding in image domain at all:
Simply let DCT act on both reference blocks and add them together, 
then devide afterwards in DCT domain (everything's linear...). Again
remember: motion compensation of encoder and decoder doesn't have to be
exactly the same, since errors don't propagate. It just has to _look_
good when decoded (actually, there is not compensation in encoder at all). 


> There is a slight bias towards negative DC. My hypotesis was: halfpel
> interpolation uses rounding_control = 0, so the total compensated
> image might indeed be a bit brighter - the formula is
>       r1 + r2 + 1 - rounding; .
>
> Further experiments confirm this - the values get swapped if I use
> rounding control of 1.
>
> The bias got bigger. Why? Because we interpolate two pictures and
> _again_ round away from zero, towards white. MPEG4 sucks, how can we
> round in the same direction twice?
> 
> Now, direct mode, the one which causes trouble:
> total : 616349
> DC -1 : 115687
> DC +1 : 31955
> 
> Can you see the problem? Once again, we're rounding towards white
> twice. This time however, motion compensation can't do nothing about
> it - it's very limited, both reference pictures are interpolated with
> the probability of 75% each, so there is 56% that they are both
> interpolated and only 6% that none. And in the end, they are
> interpolated together, again with rounding towards infinity.