Re: [XviD-devel] Adaptive quantisation

[Dirk Knop <dknop@xxxxxxx>]

Hi,

Edouard Gomez wrote:

> I don't  know if doom9 uses  to review open source  projects. But i've
> never  seen reviews using  experimental code.  Koepi's builds  are cvs
> snapshots + the  koepi's decision to include square me  or ... i would
> have never used that to test a codec. I'm not criticizing koepi, I'm 
> criticizing doom9's choice.
>
> When someone has  to review the codec, it should  use a stable release
> (or  the current  stable  snapshot,  as our  releases  are not  called
> releases). I  would have laugh if  someone had tested  mozilla 2 years
> ago with a  nightly build : "well mozilla is shit,  it crashes all the
> time, renders  an html  page in  more than 1  minute..." or  tested my
> speedtouch usb driver cvs when i'm working on new features...
>
> Perhaps  the solution  is koepi  proposes a  stable -  use  for review
> binary... don't know.
>  
I made a "plain cvs" build too which we tested on SPR. It looked even 
worse. (Somehow EPZS is working even if it isn't coded "correctly". 
There were more visible blocks with PMVfast in these extreme 
situations.). That's the only thing I modified vs. the CVS. The first 
build (doom9 used the CVS+EPZS builds for a second test, respect for 
using other binaries too and check the results) was with hardcoded "cc 
kf" treatment, which he then told "not to recommend" (I totally agree 
there, it was just a proof-of-concept or better "let's see if it works" 
version). But the next builds he used (it was from CVS 01.08.) was 
"vanilla" with EPZS and looked better (the screenshots are from that 
encodings btw.). Well, we have to see if the old luma masking code is 
working better there. The curve treatment sure did a good job, but if 
the new algo is quantizing everything below/above some thresholds away 
the results are explainable.

Well, just wanted to mention that Doom9 tried to be fair, and he was 
kind of nice in his review.

And please, with all respect, the CVS is in a stable state for "vanilla" 
builds.

If anyone try to do a PSNR check and encode something with the "new" 
luma masking code, we could compare that to the "plain" version without 
the usage of adaptive quantization to see if the impact is that bad.

Don't get too picky on me(I once tried b-frames and took the build down 
when you aske me to, gruel!), if I made a failure I'd apologize, but I 
can't see where this was wrong.

Regards,
Koepi