[MPlayer-dev-eng] FFmpeg, svn:externals and where to go from here

[Reimar Döffinger]

On Mon, Jan 24, 2011 at 02:55:51PM +0100, Diego Biurrun wrote:
> On Sun, Jan 23, 2011 at 08:10:47PM +0100, Reimar Döffinger wrote:
> > On Sat, Jan 22, 2011 at 11:42:02PM +0100, Reinhard Tartler wrote:
> > > On Sat, Jan 22, 2011 at 21:16:59 (CET), Clément Bœsch wrote:
> > > > I personally agree with removing them from the tree and use system one.
> > > >
> > > > Though, I'm not sure to understand what you plane to do for the FFmpeg
> > > > repository, but using the system one will clearly lead to problems, there
> > > > is too much potential different packaged versions of it…
> > > 
> > > FFmpeg does releases these days, so what's the problem on requiring the
> > > latest FFmpeg release (0.6 at this time)?
> > 
> > Still having the MAX_STREAMS limit is. And not wanting to be kept back
> > by having to work with ancient FFmpeg versions.
> > Also "using the system one" all sounds nice and well, but there is not
> > "system one" on neither Windows nor OSX, it will make compiling on these
> > systems a _lot_ more effort. Particularly for me, and I don't see anyone
> > else maintaining the Windows build...
> 
> This looks no harder than compiling both MPlayer and FFmpeg to me.

Which is double the effort of just compiling MPlayer.
However that is not counting the worst: either installing FFmpeg
or beating it to be useable without installing.

> What about libdvdnav/libdvdread?  Are you opposed to dropping them?
> The rate of development is much much slower than FFmpeg and changes
> will therefore be relatively rare.  Using whatever libdvd* is installed
> on the system therefore looks like a sensible course of action to me.

The difference is that between a simply "please try this dvdnav patch"
and a ca. 50 lines instruction that still don't work on all
systems (starts with the joy of /usr/local/lib not being in the
library path by default).
If the reason for slow development was libdvdnav being working fine
that would be reasonable, but the situation is rather libdvd* being
really crappy but nobody really cares so much.
That is not taking into account that there generally is no system
libdvdcss.