[XviD-devel] dark blocks in b-frames

[Christoph Lampert]

No, wait, this was only in QPel mode, right? 
Then forget it...

gruel 


On Fri, 14 Feb 2003, Christoph Lampert wrote:
> 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 
> 
> 
> _______________________________________________
> XviD-devel mailing list
> XviD-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
>