[XviD-devel] Coefficient thresholding

Michael Militzer xvid-devel@xvid.org
Sun, 18 Aug 2002 15:29:19 +0200


Hi,

> On Sun, 18 Aug 2002, Milos Spasovic wrote:
>
> > Hi,
> >
> > I folowed discussion about adding a coefficient thresholding and syskin
> > saying that improves PSNR for 0.1 dB for fixed bitrate. That might be
> > true and I trust syskin because I currently don't have access to my
> > Linux machine which I use together with gruels excellent tool for
> > measuring PSNR. However I have one trailer which I constantly use for
> > checking different motion estimations with fixed quant 3 and MPEG
> > quantization. So I tested it with coeff thresholding enabled and there
> > IS a drop in filesize compared to older builds - about 600 kb. To get
> > to the point, after watching this trailer I noticed that too much
> > details were removed, which was the most noticable on human faces. It
> > looks like TOOSMALL_LIMIT is set too high (or is that too low?). So I
> > was wondering if this coeff thresholding is necessary because the main
> > thing that makes XviD so special is IMO the amount of details it keeps.
> > So please if someone else can also compare with and without tresholding
> > I would be very grateful.
>
> We could do the following:
>
> A TOOSMALL_LIMIT of 2 already removes the danger of zero-iDCT at quant=1.
> At quant=2 and higher, zero-iDCT did not happen once in the tests I did
> since yesterday (for quant=1 without TOOSMALL it was about 6 blocks
> per 100 CIF-frames). (around 0.003% of all blocks for quant=1).
>
> We make coefficient threshholding a flag. If it's switched off,
> a value of 1 (no threshholding) is used for quant>=2 and a value of 2
> is used for quant=1. I doubt that for quant=1 the effect will be
> very visisble...

yes, that's good. I agree that a TOO_SMALL_LIMIT of 2 will not noticeably
decrease quant=1 quality. However I would prefer an integer value for coeff
thresholding instead of a flag: API 3.0 will be introduced in the nearer
future and an addtional integer option would be no problem then...

bye
Michael