[XviD-devel] better trellis?

[Radek Czyz]

Hi :)

Michael Militzer wrote:

> I suspect that trellis quantization will become (significantly) slower when
> using quantization without bias. That's simply because we have more non-
> zero coefficients among the quantized DCT coefficients and therefore more
> nodes in the trellis. I guess even when you only check for lowering levels,
> it might still be slower than the current implementation.

Yes it probably will. I tried to measure it and it was nothing serious 
(definitely not a killer) but I can't tell how much exactly, because I'm 
using C code for quantization.

Of course, I will take it into account.


> So probably, your lambda should also take motion or current avrg. texture 
> size into consideration. On the other hand: from a HVS perspective we may
> not like to have best quality in high motion scenes as the human eye may
> not be capable at all to perceive the extra quality here - oh well, just
> some thoughts...

The trellis is just a backend for HVS models. Currently lambda is fixed, 
and remains at the same value at which it used to be.

The actual implementations are supposed to take a form of HVS plugins, 
which will work together to describe the suggested quality of different 
parts of the picture. Core will simply use trellis to make these values 
actually have any effect.
Trellis is not the only way to enforce HVS results, but the most natural 
one. There is also lambda during VHQ and there are motion skip 
thresholds, just to name two - but I would like to have the trellis part 
fully functional before I do anything else.

Thanks for the mail,
Radek