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

[Diego Biurrun]

On Tue, Jan 30, 2007 at 06:22:17PM +0100, Reimar Döffinger wrote:
> 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...

It's still significant and since upgrading should not be that hard ..

> > > > > 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.

Port stuff to what?  I don't quite follow you here.

> 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

If speed is so close we should move over to the FFmpeg implementation
IMO.  This way it will get more widespread testing and possible bugs
will get shaken out.

Diego