[XviD-devel] Comparison "old" vs "new" adaptive quant code

[Christoph Lampert]

Thank you for the test. My first statement: If the average quantizer is
less than 4, the adaptive quant should not give higher results than 8. 
I simply cannot believe that this will be useful. So it's not wonder the
new ME gave bad results. 

> Further I tested EPZS^2 vs. PMVfast using the same settings and it shows 
> that the current implementation is a little bit better (in the sense of 
> average quantiser reached) as PMVfast, 

Do you mean EPZS vs. PMVfast (so no PMV_USESQUARES) or EPZS^2
vs. PMVfast^2 (including PMV_USESQUARES), or a mixture? Either both or
none should have SQUARES, otherwise the test is not "fair". 

You can't just add 1.52% to the PMVfast quantizer and say that's the
corrected one. The relationship quantizer<->filesize is not that simple. 
Similar, but not exact enough to do it like this. 

> even if it's "buggy". If someone 
> could clarify what is working wrong there I would appreciate it, since I 
> _believe_ I ran into a situation where that code was "smearing" a wrong 
> detail through the picture (residues of a light during camera movement 
> having a "trail") which isn't there when using PMVfast code - is that an 
> error that could be caused by this?

Sounds like an error, indeed, maybe connected to adaptive quantization? 
EPZS is (if at all) not tested with combinations like adaptive quant,
modulated quant etc. 

> A further note, if you take a look at the screenshots over at doom9 in 
> the comparison, take a look at the brighter picture of XviD, there are 
> strange yellow/greenish spots on the left side of the picture, 
> alternating every pixel ("on-off toggle"). One user over at doom9 found 
> some scenes where he could see that, and when looking at my clips I can 
> verify that it's there sometimes. Is that intentional, a feature, or 
> even a bug?

That's _definitely_ a bug! Sh*t! I don't see it in the first screenshot,
but it's e.g. here: 

http://www.doom9.org/images/codecs/matrix-xv-142142.jpg

And of course, I have no explenation, but a suggestion: 
If it has to do with interpolation, could _please_ somebody remove the
illegal memory accesses (using one more row than allocated) in
image v- and hv-interpolation? 

> Ah, and another one:
> Should I update VFW/DShow so they include the xvid.h from the core 
> sources? I think this is a step which should be made. And I wanted to 
> add #defines for EPZS and other things, if I find them, so that in 
> XviD.h we get a small "feature enable/disable" section. I would add 
> something like a #define-based XVID_SPECIAL_BUILD comment, so it is 
> easily to see which of these experimental features are activated in a build.
> Any objections?

xvid.h : yes

What kind of "defines" for EPZS? You can already acticate it at compile
time by defining   SEARCH16=EPZSSearch16  SEARCH8=... etc.
But I'd say wait a little with ME related stuff. There is a rewritten ME 
from sysKin in queue to become default and then we will use function
pointers for all anyway, so EPZS will just be another flag. 

gruel

-- 
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