remove internal minilzo (was: Re: [MPlayer-dev-eng] [PATCH] make mplayer's liblzo support compile with lzo 2.x)
diego at biurrun.de
Tue Feb 13 11:19:51 CET 2007
On Thu, Feb 01, 2007 at 11:29:28AM +0100, Diego Biurrun wrote:
> On Thu, Feb 01, 2007 at 01:09:41AM +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?
> > With latest changes liblzo is no longer used. But ve_nuv.c depends on
> > our minilzo. IMO it would be preferable to apply the configure part of
> > this patch, change ve_nuv.c to use liblzo (hopefully someone volunteers,
> > should be at most 4 lines), and remove minilzo.
> That's fine with me. We should eventually get rid of all the stuff in
> libmpcodecs/native/ and use FFmpeg instead.
> > Requiring liblzo2 for something that is as obscure as I believe ve_nuv
> > to be is okay IMO...
> I just checked, liblzo2 is not bigger than liblzo1, performance is
> better. So this should be an acceptable forced upgrade.
OK, I'm going to commit support for liblzo2 (only) and remove our
internal minilzo copy. If you object, raise your voice before the
weekend, at which point I have planned to commit.
More information about the MPlayer-dev-eng