Updating mplayer: how about using bundled ffmpeg?

[Julian Sikorski]

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