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

[Reimar Döffinger]

On Wed, Mar 17, 2010 at 01:03:21PM +0100, Diego Biurrun wrote:
> * 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

Hm? IIRC FFmpeg was a lot slower originally and even now is still a bit slower.
And upstream is a lot slower, so it seems to me that removing it would remove
the fastest decoder available.
Not that I mind much.

> * 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

Uh, this again to my knowledge is the only way to play LATM files.

> * 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?

Not particularly, but I wonder when FFmpeg got faster?
IIRC it was always slower... Of course that might depend on the CPU,
libmpeg2 only supports up to SSE I think, so with CPUs that support
more than that libavcodec probably has a chance.

> * 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?

That basic functionality should be available without the user having
to download/compile/install extra libraries.

> * 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.

FFmpeg Ogg support is still far from enough for use, it does not work with
libtheora decoder and I also have a sample around that completely hangs
(http://samples.mplayerhq.hu/ogg/packetsize0.ogv I think).

> * 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?

Their standalone build-system still is a pain and confusing due to having
two methods available, not sure if it's obvious how link libdvdcss statically.

> * 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.

In principle fine, except that upstream is on a different server and I don't
know what will happen when checkout or update is done while it is down.