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

[Reimar Döffinger]

Hello,
On Mon, Jan 29, 2007 at 06:58:22PM +0100, Diego Biurrun wrote:
> On Sat, Jan 27, 2007 at 04:36:52PM +0100, Reimar D?ffinger wrote:
> > On Fri, Jan 26, 2007 at 05:08:20PM +0100, Carl Eugen Hoyos wrote:
> > > On 2007-01-17 14:29, Bernhard Rosenkraenzer wrote:
> > > > SSIA -- the patch is about as simple as it can get, given the API is almost 
> > > > unchanged.
> > > 
> > > Unfortunately, Oberhumer decided to change the installation directory for 
> > > lzo1x.h to .../include/lzo for version 2:  
> > > http://www.oberhumer.com/opensource/lzo/lzonews.php (Misc), so I don't think 
> > > your patch will help for typical(?) installations.
> > > 
> > > But why keep support for liblzo1? Most libraries are only supported by mplayer 
> > > if their newest versions are used. What about the attached patch?
> > 
> > Actually why support liblzo at all? ve_nuv.c e.g. doesn't support it...
> > We already have included minilzo, and attached is a patch illustrating
> > what I want to do anyway in the long term, namely using the ffmpeg lzo
> > after it is moved to libavutil (for the decoding stuff, will have to see
> > about the encoding later on).
> 
> Yes, this sounds reasonable.  Is there any advantage of using liblzo
> over our internal minilzo and/or the FFmpeg implementation?

vs. minilzo: our minilzo is old and has horrible performance on 64 bit
systems, liblzo2 should be better.
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.

Greetings,
Reimar Döffinger