Re: Updating mplayer: how about using bundled ffmpeg?

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