[XviD-devel] dark blocks in b-frames

[Christoph Lampert]

On Fri, 14 Feb 2003, Radek Czyz wrote:
> 
> So the question is - WHY COMPENSATED IMAGE IS TOO BRIGHT _or_ WHY
> "current" image is too dark. And also, why motion estimation doesn't
> do anything about it - we all know that sad-based ME is very sensitive
> to mean luminance.

Okay, I never had problems with blinking blocks, so maybe its compiler
dependent, too, and my first idea isn't too ridiculous. Maybe by checking
several routines, we'll find the right one in the end. 

First candidate for a check is the transfer-function which is only called
for direct and interpolated mode. 

Is it possible that the calculation of r in  transfer_8to16sub2_c 
is done wrong, depending on the compiler? 

int r = (ref1[j * stride + i] + ref2[j * stride +i] + 1) / 2;

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.

My gcc doesn't do this, it always seems to calculate with ints. But who
knows... 

gruel 
------------------------------------
void
transfer_8to16sub2_c(int16_t * const dct,
					 uint8_t * const cur,
					 const uint8_t * ref1,
					 const uint8_t * ref2,
					 const uint32_t stride)
{
 uint32_t i, j;

 for (j = 0; j < 8; j++) {
  for (i = 0; i < 8; i++) {
 	uint8_t c = cur[j * stride + i]; 
	int r = (ref1[j * stride + i] + ref2[j * stride +i] + 1) / 2;
//fprintf(stderr,"%d %d\n",((int16_t)ref1[j*stride+i] +(int16_t)ref2[j*stride+i]+1)/2,r);
	if (r > 255) {
		r = 255;
	}
	//cur[j * stride + i] = r;
	dct[j * 8 + i] = (int16_t) c - (int16_t) r;
}
}
}

Btw. there does the check for (r>255) come from???  
Since 0 <= [0,255]+[0,255]+1 <= 511   and 511/2 = 255  (/2 rounds to 0),
the path is never taken... 

gruel