[XviD-devel] Adaptive quantisation

[Michael Militzer]

Hi,

----- Original Message -----
From: "Dirk Knop" <dknop@gwdg.de>
To: <xvid-devel@xvid.org>
Sent: Sunday, August 04, 2002 8:35 PM
Subject: Re: [XviD-devel] Adaptive quantisation


> Michael Militzer 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.
> >
> >you're both right. The daily binaries including untested experimental
code
> >are dangerous (for Joe User). I've already written doom9 about this (and
> >because I liked to know what the problem really was). What is a bit
> >disappointing for me is that doom9 didn't wrote me at all that he had any
> >problems with the comparison. We were in contact when he did his last
> >comparisons and recently we had some (more or less unimportant) talk
about
> >"when will b-frames be ready etc.". I would have advised him to simply
used
> >an older build...
> >
> Hey, I really tried my best. For all other people this code works, only
> now we got aware that there's something wrong with the luma-code, which
> explains some effects which could be seen.
> Btw., the comparison is about the progress the codecs made, and about
> that what the users get to download from the net. So if you advise him
> to use an older build, this wouldn't be the real case somehow.
[...]
> So please, let's stop bitching at the persons who dare to release
> binaries and let's see how to prevent to get unreviewed code into CVS.

no don't get me wrong here, no offense to you. I believe you if you say that
"vanilla" builds didn't work either. But that indicates that we have a
problem and I would have appreciate it if doom9 had contacted me as he did
before. Now I have no idea what went wrong. Blockyness can be caused by a
lot of things, simplest is that the quantizers were too high (could be
caused by lumi masking - btw: was lumi masking activated for the SPR encode
at all?), worst would be a serious problem within core. btw: I have SPR
myself and used a (longer) sequence of it for my qpel encoding tests: I had
no blockyness problems (but I had a problem where you can see a "quality
jump" whenever a keyframe is decoded - that's something doom9 mentioned
already in his last comparison and I didn't believed it at first, but I have
to admit it's really annoying) - So there's lots of work to do now...

bye
Michael