[MPlayer-dev-eng] [RFC] internal library copies

Diego Biurrun diego at biurrun.de
Wed Mar 17 13:03:21 CET 2010


We carry around a bunch of externally available libraries and I think
it's time to review the situation around them.  Some of them we should
keep, others could be dropped.

* liba52

The internal copy was disabled some time ago, FFmpeg is both faster and
more featureful.  We support building against the external version.  Our
copy is patched, but upstream is dead and the patches have been rejected
IIRC.
verdict: drop

* libfaad2

Nobody touch this one, I reserve the privilege to remove it! ;-)
FFmpeg is way faster.  There are a few AAC variants that FFmpeg does not
support (yet), but now that SBR has been implemented, all the important
things are covered.  Compiling against the external version works fine.
verdict: remove

* libmpeg2

Nowadays FFmpeg is faster and should be better maintained.  Unfortunately
we cannot compile against the external version.  This should not be hard
to fix.  If it gets fixed, we could remove libmpeg2 IMO.
Is anybody interested in fixing external libmpeg2 compilation?

* libass

This is being kept around as a convenience for users, but the internal
version is outdated compared to the internal one.  What stops us from
droppping it and compiling against the external version instead?

* tremor

Last time I checked, we could not compile against the external version.
IIRC we require parts of this for our internal Ogg demuxer.  I don't
quite remember the details, it would be appreciated if somebody could
shine a light on this.  Now that FFmpeg's Ogg support has been markedly
improved it is desirable to break this dependency if possible.
Fixing compilation against external Tremor would be welcome.

* mp3lib

Upstream exists again.  Compiling against the external version is a
welcome feature.  FFmpeg does not expect to grow a float decoder in
the foreseeable future, so I expect mp3lib to stay with us for now.

* libdvdread4/libdvdnav

They are only externals and unpatched, kept around for convenience.
Admittedly, I haven't put much thought to the pros and cons of keeping
them around.  Opinions?

* libdvdcss

We have an internal copy for convenience, but it is unpatched.  It could
at least be converted into an svn:external, same as the other libdvd*
libraries.


Did I forget or overlook anything?

Diego



More information about the MPlayer-dev-eng mailing list