[MPlayer-dev-eng] [PATCH] make mplayer's liblzo support compile with lzo 2.x

[Reimar Döffinger]

Hello,
On Tue, Jan 30, 2007 at 03:19:06PM +0100, Diego Biurrun wrote:
> On Tue, Jan 30, 2007 at 03:02:18PM +0100, Reimar Doeffinger wrote:
> > On Tue, Jan 30, 2007 at 02:41:04PM +0100, Diego Biurrun wrote:
> > > On Mon, Jan 29, 2007 at 08:43:41PM +0100, Reimar Döffinger wrote:
> > > > vs. minilzo: our minilzo is old and has horrible performance on 64 bit
> > > > systems, liblzo2 should be better.
> > > 
> > > So maybe we should just update the internal minilzo?
> > 
> > We could, but actually I think current one is "good enough", too.
> 
> Even if it has horrible performance on 64 bit systems?  I faintly
> remember seeing some distro packages (SUSE?) that had updated the
> internal minilzo...

Horrible because it is 20 % slower. Which probably means that whatever
uses it will need now 0.12 % instead of 0.1 % CPU with that kind of
modern CPU...
But if speed is a concern, there also are asm-optimized liblzo variants,
but I think with such an obscure (as in who-still-uses-that?) feature
there is no need to have all the knobs to get the last % of speed built-in
and maintained.

> > > > vs. ffmpeg lzo: ffmpeg needs padding, supports only decoding and only
> > > > for 1x variant (not aware of any other variant being used though).
> > > > encoding is not a good argument though, since as said that currently
> > > > can't use liblzo either.
> > > 
> > > Have you benchmarked liblzo against fflzo?
> > > 
> > > I think the padding issue is just a matter or lobbying Reimar to
> > > implement it in his FFmpeg decoder ;-p
> > 
> > Huh? The padding is not a problem really, it's just not completely
> > API-compatible because of this. Also the code supports disabling this
> > requirement but then it is probably slower than liblzo. With padding, it
> > should be quite a bit faster (untested though) ...
> 
> If it's faster, is there a reason left to keep liblzo support apart from
> encoding?

Probably not (and encoding is only a point for minilzo, we can not use
liblzo for it anyway), except that I did not yet port stuff to use it.

Here is benchmark stuff for decompressing my local MPlayer binary (note
that with numbers so close you can probably find files that favour
either one or the other).
System: Linux 64 bit, Athlon 64 3200+, runnning at 800 MHz.

ffmpeg lzo:
937079770 dezicycles in lzod, 1 runs, 0 skips
869686895 dezicycles in lzod, 2 runs, 0 skips
835646440 dezicycles in lzod, 4 runs, 0 skips
818764912 dezicycles in lzod, 8 runs, 0 skips
810343002 dezicycles in lzod, 16 runs, 0 skips
805921584 dezicycles in lzod, 32 runs, 0 skips
803809516 dezicycles in lzod, 64 runs, 0 skips
802775508 dezicycles in lzod, 128 runs, 0 skips
802516218 dezicycles in lzod, 256 runs, 0 skips


liblzo2 as my gentoo install has installed:

lzo1x_decompress_safe:
939982590 dezicycles in liblzod, 1 runs, 0 skips
873222585 dezicycles in liblzod, 2 runs, 0 skips
840145167 dezicycles in liblzod, 4 runs, 0 skips
823173808 dezicycles in liblzod, 8 runs, 0 skips
814640756 dezicycles in liblzod, 16 runs, 0 skips
810238282 dezicycles in liblzod, 32 runs, 0 skips
808126587 dezicycles in liblzod, 64 runs, 0 skips
807051762 dezicycles in liblzod, 128 runs, 0 skips
806501507 dezicycles in liblzod, 256 runs, 0 skips

lzo1x_decompress (for fairness's sake, I can not see any single place
in MPlayer where it would be acceptable to use this since it does not buffer
boundary checking at all):
870429110 dezicycles in liblzod, 1 runs, 0 skips
799137045 dezicycles in liblzod, 2 runs, 0 skips
763513827 dezicycles in liblzod, 4 runs, 0 skips
745129240 dezicycles in liblzod, 8 runs, 0 skips
736588636 dezicycles in liblzod, 16 runs, 0 skips
731812726 dezicycles in liblzod, 32 runs, 0 skips
729409146 dezicycles in liblzod, 64 runs, 0 skips
728233607 dezicycles in liblzod, 128 runs, 0 skips
727697820 dezicycles in liblzod, 256 runs, 0 skips

Greetings,
Reimar Döffinger