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

[Reimar Doeffinger]

Hello,
On Wed, Jan 31, 2007 at 09:44:40AM +0100, Diego Biurrun wrote:
> On Tue, Jan 30, 2007 at 06:22:17PM +0100, Reimar Döffinger wrote:
> > 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 ..

I won't object to someone doing it, as long as that someone is not me.

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

To the ffmpeg LZO API.

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

I doubt there are any bugs in that code :-). I posted a patch on
ffmpeg-dev that at least on some workloads will place ffmpeg LZO in
speed right between the safe and unsafe liblzo variants (i.e. ca. 4%
faster than liblzo). Though it assumes the C compiler has a memcpy
builtin for fixed-size memcpys.
Btw I find it amazing that all the years vd_lzo only worked becaused it
used the unsafe lzo decompression...

Greetings,
Reimar Doeffinger