[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