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

[compn]

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

isnt there some problem wrt downmixing ?


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

only if you fix all of the spammed messages in the ffaac decoder.
like this one which occurs 10 per second in many files...
[aac @ 021cc160]SBR not implemented. Update your FFmpeg version to the
newest one from SVN. If the problem still occurs, it means that your
file has a feature which has not been implemented.


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

i dont remember any reason to keep it. dvdnav?

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

external version is hosted in uau's git mplayer repo iirc. the current
situation is optimal (without having a huge flamewar no doubt).


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

fixed point vs floating point? is tremor still useful on arm vs
ffvorbis?

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

isnt playing encrypted vobs (brute force) still on the wishlist? be
nice to have this feature. maybe ffmpeg will step in?

-compn