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

Michael Militzer xvid-devel@xvid.org
Sat, 17 Aug 2002 14:32:20 +0200


Hi,

----- Original Message -----
From: "Christoph Lampert" <chl@math.uni-bonn.de>
To: <xvid-devel@xvid.org>
Sent: Saturday, August 17, 2002 2:16 PM
Subject: Re: Re[2]: [XviD-devel] xvid + bframes and mplayer/ffmpeg decoding


> On Sat, 17 Aug 2002, Michael Militzer wrote:
> > The MPEG-4 VM 18 requires the coeffs to be clipped into the range [-128,
> > 127] (8 Bit) but the VM 18 seems outdated and the reference codecs
(momusys
> > and f-dam) use 12 Bits to code coeff data in fixed length mode.
Therefore
> > clipping is not necessarily needed at all. Latest XviD versions don't
clip
> > the coeffs anymore, so all clamping artifacts should be gone...
>
> If I'm not mistaken, it should be clipped to   [-2^(bpp+3), 2^(bpp+3)-1]
>
> So for 8bit material (like XviD) that's [-2048,2047], which I guess means,
> no clipping is needed at all.
>
> Still that doesn't solve any of the iDCT "problems". Would it be much work
> to either adapt iDCT  that nonzero->zero is not possible anymore or
> to detect if the output is all zero?

well, adapting the idct is much work, especially if the idct should still be
fast after the modification. I don't think this would make sense. But we
could switch to another idct or simply reactivate coeff thresholding for now
(maybe define a TOO_SMALL_LIMIT of 2 or 3) which should fix the problem.

However I'm still a bit confused about this problem: our current idct has a
peak error of 1 (iirc) so I don't see how zeroes should be introduced out of
non zero coefficients, not even for quant 1...

bye
Michael