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

[Diego Biurrun]

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.

> My suggestion would have been to stick with SVN after all unless/until
> we can get libdvd* as git as well at least, and hack configure to do
> git clone/git pull --rebase on its ffmpeg checkout.
> The proposed logic would be
> 1) check if ffmpeg/.svn exists, if yes exit and tell user to remove or
> replace it
> 2) if ffmpeg/ does not exist, do a git clone and create a mp_auto_pull file
> 3) if ffmpeg/mp_auto_pull exists, run git pull --rebase
> 4) otherwise do nothing, assuming the user has ser up everything manually in
>    a way that will work. Possibly do some sanity-checking and/or print a warning.

A build script like this is not an unreasonable idea.  I've toyed with
the idea myself and Uoti has implemented something similar in Python.
Reports about it were very mixed, however.

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.

Diego