[MPlayer-dev-eng] [PATCH] make mplayer's liblzo support compile with lzo 2.x
Diego Biurrun
diego at biurrun.de
Tue Jan 30 15:19:06 CET 2007
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...
> > > 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?
Diego
More information about the MPlayer-dev-eng
mailing list