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

[Dominik 'Rathann' Mierzejewski]

Hi,

On Wednesday, 17 March 2010 at 13:03, 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.

> * 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 am, and IIRC I did some work in that area in my private tree.
I won't have time to work on this before the summer vacations, though.

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

Our tremor code is based on some ancient version of upstream code.
Current code is so different that I don't know how feasible it is
to build against it.

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

I remember trying to hack support for external version, but the API
is different and also MPlayer seems to be abusing some internal APIs
as usual. I will try to work on this again, but not before summer.

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

AFAIK all major distributions have both our libdvdread and our libdvdnav
forks packaged, so this seems useful only for Windows environments.

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

svn:external pointing to a repository outside our control is asking
for trouble IMHO. I would like to see libdvdcss gone from our tree, though.
Is there any reason why people can't download it from upstream and install
separately? It's not even necessary for building MPlayer.

Regards,
R.

-- 
MPlayer http://mplayerhq.hu | RPMFusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
	-- from "Collected Sayings of Muad'Dib" by the Princess Irulan