Updating mplayer: how about using bundled ffmpeg?

[Marcos Felipe Rasia de Mello]

Em 27 de fevereiro de 2012 08:41, Julian Sikorski <belegdol at gmail.com> escreveu:
>
> W dniu 27.02.2012 05:16, Andrew Schultz pisze:
> > Julian Sikorski wrote:
> >> Hi,
> >>
> >> I was trying to update mplayer and most of the problems I am having are
> >> due to using shared ffmpeg, which is discouraged and unsupported by
> >> upstream. The latest error is:
> >>
> >> libmpdemux/mp_taglists.c:27:34: fatal error: libavformat/internal.h: No
> >> such file or directory
> >>
> >> when trying to build 20120204 snapshot. Looking at the svn log, this was
> >> added in revision 34243 (from 20111023). This all seems to indicate that
> >> trying to use system ffmpeg is an uphill battle which will always going
> >> to keep our mplayer behind, as well as piss upstream off when we come
> >> asking for help.
> >> The alternative would be to switch to mplayer2. What are your opinions?
> >
> > It looks like the internal.h change was just in response to changes in
> > ffmpeg rather piling on further internal linkage.  The previous mplayer
> > package in rpmfusion included libavformat/riff.h which simply provided
> > the AVCodecTag struct (looks like a trimmed down version of ffmpeg's
> > riff.h).  Anyway, mp_taglists.c says it's including internal.h to get
> > that symbol and if I provide a ffmpeg/libavformat/internal.h that has
> > only that symbol (everything else ripped out) then mplayer compiles and
> > links succesfully (and seems to work).
> >
> > I tried a more recent mplayer snapshot but that failed to build as
> > mplayer has added bits to use (public) bits from ffmpeg that were added
> > after ffmpeg 0.10.  It looks like that change landed in mplayer on Feb 14.
> >
> > http://lists.mplayerhq.hu/pipermail/mplayer-cvslog/2012-February/043662.html
> >
> >
> In such case I think we should switch to mplayer2 instead of hacking
> ffmpeg/mplayer to pieces to make it build with system ffmpeg, only to
> hear "try the latest svn snapshot" from upstream if something goes south.
>
> Julian
>

Me too. The only issue I can see in mplayer2 is that it lacks a
MEncoder like tool. Outside the main repository, they have an 'encode'
branch

http://git.mplayer2.org/divverent/mplayer2.git

but I don't know its status.

Marcos