[XviD-devel] HUGE ME regressions between beta1 and beta2

[Michael Militzer]

As always, attachments got stripped. So have a look here:

http://www.xvid.org/images/carphone.png
http://www.xvid.org/images/highway.png
http://www.xvid.org/images/mother.png
http://www.xvid.org/images/paris.png
http://www.xvid.org/images/tempete.png

Regards,
Michael


Quoting Michael Militzer <michael at xvid.org>:

> Hi Radek,
> 
> well, I've basically just changed our lambda tables. Before, the values for
> lambda were borrowed from h.264 it seemed however didn't fit XviD's linear
> qscale at all. In result, R-D performance especially for higher QPs was
> absolutely horrible. I've changed it to a more lambda = 0.85*Q scheme (ok,
> can't recall the exact constant from memory now). I've tested the change
> for VHQ and non-VHQ modes and had always superior performance, sometimes 
> with really huge gains especially a low bit-rates/high quants. 
> 
> I've attached my original mail to the list at the end of this mails and also
> reposted some of the R-D curves I did at those times. Your testing case is
> covered as well (it seems).
> 
> Sure we can postpone 1.1 final until this problem is fixed. BTW: did you use
> a standard sequence for your test so we can reproduce the problem?
> 
> Regards,
> Michael
> 
> 
> Quoting Radek Czyz <radoslaw at syskin.cjb.net>:
> 
> > Hi everyone,
> > 
> > Apparently our testing community sucks ;))
> > 
> > There was a HUGE quality and speed regression between beta1 and beta2. I 
> > narrowed it down to SAD-based ME. The major changes in that time was 
> > Isibaar's new lambda code, but apparently we have hardly any logs what 
> > happened exactly (well, we've got cvs, I'll check that).
> > 
> > For fast settings (no VHQ, no trellis, no chromaME, defaults otherwise):
> > 
> > Beta1's ME:  time 1:19 filesize 26.2MB psnr 41.19dB
> > Current ME:  time 1:24 filesize 28.8MB psnr 41.14dB
> > 
> > 
> > What the heck happened? ;_;
> > 
> > I suggest we postpone 1.1final until we figure this out - looks like all 
> > speed improvements over 1.0 are gone (10% slower at these settings, 5% 
> > slower at defaults), and 10% more filesize for *lower* quality is... bad.
> > 
> > Radek
> > _______________________________________________
> > XviD-devel mailing list
> > XviD-devel at xvid.org
> > http://list.xvid.org/mailman/listinfo/xvid-devel
> > 
> 
> 
> ----- Forwarded message from Michael Militzer <michael at xvid.org> -----
>     Date: Mon, 14 Mar 2005 19:59:37 +0100
>     From: Michael Militzer <michael at xvid.org>
> Reply-To: Michael Militzer <michael at xvid.org>
>  Subject: low-bitrate patch
>       To: xvid-devel at xvid.org
> 
> Hi all,
> 
> I've committed a patch to cvs that improves XVID's performance at low-
> bitrates by using better lambda values for R-D vector search. By this also
> mode decision (SAD-based) is improved at low-bitrates. At mid/higher
> bitrates
> there's no change in performance, so only people who aim at really low
> bitrate (and quality) encodes will benefit from this patch.
> 
> I've attached some R-D graphs that compare the behavior of patched and 
> unpatched XVID for various sequences and different bit-rates. Note that I've
> used a logarithmic scale, so that the differences at low bitrates can be
> better perceived. As can be clearly noticed, the compression performance is
> enhanced significantly at very low bitrates (up to 2-3 dB PSNR).
> 
> Well, it's another question how useful this patch actually is because such
> extremely low bit-rates are barely used. But for completeness, XVID should
> perform equally great at all bitrates...
> 
> bye,
> Michael
> 
> ----- End forwarded message -----
> 
> 
> 
>