Re[2]: [XviD-devel] xvid + bframes and mplayer/ffmpeg decoding

[Christoph Lampert]

On Fri, 16 Aug 2002, Radoslaw Czyz wrote:

> > Ouch! Is this in the standard? Where? Is this for B-frames, too?
> 
> > Because XviD does not check iDCT results to decide if a block should be
> > encoded. For B-frames, iDCT isn't even _done_!
> 
> Yes it does. It won't encode a DCT block if all coefficients are zero.
> The sum of coefficients is computed during quantization, and block is
> coded only if (sum >= TOOSMALL_LIMIT) i.e. (sum >= 1). No problems
> there.

Just as I said: It doesn't check i(!)DCT. It does DCT and Quant and
decides on that if the block should be coded. 

I guess it was meant like this: It could be possible that there is 

small non-zero coefficients in quantized DCT data, so the block is coded
=> small coefficients in dequantizer DCT data (if quant was small)
=> but _iDCT_ returns _all zero_ because of rounding. 

In theory, this cannot happen with iDCT, but with rounding, going
e.g. from sum=1 to 0 is possible. 

Xvid does not check for such blocks (which results in only zeroes for 
motion compensation, so _if_ they appear, they might again and again and
again).
Then a different decoder comes, its iDCT does _not_ return all zero on the
quantizer DCT, so there is an error and it accumulates if the block is
encoded several times. 

It sound logical do disallow this for I/P-frames. For B-frames, I don't
care.

Christoph 


-- 
Christoph H. Lampert chl@math,uni-bonn,de | Diese Signature wurde maschi-     
Beringstr. 6, Raum 14 Tel. (0228) 73-2948 | nell erstellt und bedarf
Sprechstunden: keine, aber meistens da    | keiner Unterschrift. AZ 27B-6