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

[Diego Biurrun]

On Wed, Mar 17, 2010 at 07:50:08PM +0100, Reimar Döffinger wrote:
> 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.

Hmm, you disabled liba52.  Can somebody provide numbers?  I think FFmpeg
was faster, even for my K6-III...

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

But are LATM files common?

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

Well, you switched to FFmpeg as the default decoder for MPEG-2 (IIRC)..
I don't think there is a point in keeping local copies of libraries that
are not even used by default...

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

Do we want to carry around local copies of everything?  I have changed
my mind in this regard over the years, I think we should strive to get
rid of internal library copies.

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

That sample plays fine in ffplay for me while mplayer hangs, so it looks
more like a problem on our side..

What about switching to lavf demuxer for Ogg?  The big issue was seeking
with Theora video, but that has been fixed.

Diego