[XviD-devel] codec performance

[Bobololo]

> okay, it was called FrameAnalyser.

Thanks for the links, it seems interesting. It could be a very useful
tool for algorithms study and improvement.

[VfwBench source code]

> iam interested. especially if we could benchmark more processors...
> on my outdated box, xvid leaps over divx5 in terms of fps.

No problem, let me just a little time to finish the cleaning and I
will be able to package it and provide it. Btw could Xvid hosts
theses files ?

It'll work on Win2k and Pentium+ processors  (i.e with cpuid and
rdtsc) . It's just too painful to support everything, especially in
MS wonderland.

> the quality/speed of amp4 is rather impressive. can you elighten us
> as to how such high fps were acheived? hardcore assembly
> optimizations, or neat m.e. tricks?

Most of load consuming functions are written in a very straigth
forward mmx/sse assembly that can't be considered as "hardcore"
assembly. They provide to the C implementation a speed increase factor
of about 2. When mmx/sse functions are disabled (except the dct/idct),
I guess the encoder is on the average a bit slower than DivX.
For us, the goal of coding some functions in asm is to guess rapidly what
it is possible to gain on our embedded platform, not to be "the fastest
on the planet" like 3ivx :))

Actually, a very important effort has been made on the encoder
architecture and algorithms (so that this time could be qualified as
"hardcore" optimized algo :)). For instance, even on a PC, me takes
less time than the dct stuff.

If you analyze rigorously the benchmark and in particular the
correlation between the results and the sequence type, I'm convinced
you can easily guess some of the tricks we (and the ones from 3ivx and
Divx) use :)

It's the "problem" of a small set of standard sequences and objective
measurements. They tell much more than subjectives impressions ...

Bobololo.