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

[Diego Biurrun]

On Tue, Jan 25, 2011 at 10:32:29PM +0100, Reimar Döffinger wrote:
> 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.

I still believe this can be solved by some script that fetches all
components, compiles them and then builds MPlayer.  Would this be
sufficient for you to consider dropping libdvdread/libdvdnav?

I volunteer to create something suitable in this case.

Diego