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

[Reimar Döffinger]

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

Just as a reminder to myself (unless someone else implements it), step 3
should also depend on at least ffmpeg but possibly also MPlayer being at HEAD
to avoid interfering with regression testing.