[XviD-devel] dark blocks in b-frames

Christoph Lampert chl at math.uni-bonn.de
Fri Feb 14 17:00:16 CET 2003


On Sat, 15 Feb 2003, Radek Czyz wrote:

> Hi,
> 
> >ref1[N] and ref2[N] are both uint8_t. Is it possible that the compiler
> >decides to calculate the sum in 8bits unsigned before dividing by 2, thus
> >overflowing if the sum is larger than 255? Then of course r would be too
> >small, and since r is subtracted from c, the values would end up being too
> >large = bright.
> 
> I had the same idea, and I changed the code to
> 
>   int r = ((int)ref1[j * stride + i] + (int)ref2[j * stride +i] + 1) / 2;
> 
> And it didn't help. Please remember that we're talking about the
> values being too big by 2..5 ...

Okay, a lot of questions, because I still coulnd't produce any blocks. 
Just some ideas what I would check, if I could: 

Does it happen without INTER4V? If yes, always switch that off, it makes
analysis of direct mode much easier.  
How did you notice the image was too bright? Did you output the
compensated pic (maybe mean value of blocks after compensation)? Or did
you get that impression from the DCTed data? Is it really reproducable
now, so can you "measure" it at some point in the processing queue? 

If yes: Does the bias depend on quantizer? 
If I'm not mistaken, the "too bright" effect is there also 
without "too dark" blocks, but not always visible due to 
quantization. So it would be a possible to check if it is only there for
DIRECT mode, or for the complete picture. Is it present if all DIRECT
blocks are forced to be INTERPOLATE? 

gruel 



More information about the XviD-devel mailing list