[XviD-devel] Coefficient thresholding

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


Hi,

> > 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...
>
> Except for that people will be able to change it.  ;-)
>
> Thing is, I don't like a new integer when there are only
> 2 or 3 "sensible" values.
> Take e.g. framedrop, there it's it's okay. 0-100 is a sensible range.
> But having the choice between 2, 3 and maybe 4? As you heard, a hardcoded
> value of 3 is too much already in some cases...

well, didn't we use a value of 7 in first place without any further
restrictions? So values ranging from 1-10 might be reasonable depending on
the quant value...

Also I had not planned to include this option into vfw at all, I don't even
think it would be a good idea to allow the user to switch coeff thresholding
on or off. There are already too much switches 99% of the users do not
understand - but having an option in the API (for testing without
recompiling) doesn't do any harm...

> Maybe also we shouldn't take the sum, but the sum-of-squares, because
> four times 1 might give completely different results from one times four.

yes, this could help

> I rather think we should implement some more clever "automatic" for
> this (like in H26.L), instead of giving people the chance to "optimize"
> their setting for one movie, then encode another one with the same
> setting, which give horrible artefacts and they don't remember what the
> did...

I'm always in favour of "more clever" solutions. But I also remember I had a
look at the h.26L method and I think they used information for their
decision criteria that we don't have at all (I don't remember exactly what
it was exactly), but the h.26L method seemed very h.26L specific (?).

btw: talking about advanced solutions: It might be also possible not only to
drop coefficients completely (by not coding them), but we could also
slightly modify coeffs so that a shorter codeword will be used during mb
coding. This could sometimes save lots of bits (for example if after a small
change a vlc instead of a flc word could be used) while introducing only a
small additional error...

bye
Michael