Currently, mplayer (9999 and snapshots) use libav. As far as I can see, this does not follow upstream since they pull from ffmpeg (ie, ffmpeg.org, where the git is hosted by videolan). According to Reimar, libav isn't officially supported: http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2011-March/067919.html [the whole thread might be interesting for those who haven't followed and want to jump in the discussion.] I think we should use ffmpeg if we want to continue to bundle it, however, I'd like to propose something more pragmatic that we should have done years ago: drop the bundled ffmpeg, force using the system one and depend on virtual/ffmpeg. This will let people chose while reducing the compile time/size/security issues of mplayer. If nobody objects, I'm going to do this and push a new snapshot within one week. CC'ing (sorry for double mails if there are) people that may want to correct what I've stated and whose opinion might matter on the issue (even a "I dont care" is fine :) ) [PS: for -9999, I'm not even talking about the infamy reported on bug #359225 comment #3]
Hum, well the internal libav works, i did quite lot of testing before i commited that thingus :) The problem is that even with external-ffmpeg you need the internal tree because some symbols are linked and compiled from there. (for testing just use external-ffmpeg and remove the ffmpeg folder in the source tree, it will fail) So as-is external-ffmpeg is no-go I fixed the live version, it really slipped my eye that i store it into same folder :)
This is what for is mplayer2 good, it can link to external ffmpeg completely.
Created attachment 268445 [details] dumping ffmpeg from mplayer The point of bundling ffmpeg was to do what upstream recommands, which point we lost by switching to libav. IMHO, if we are not going the recommandations, better do what a sane distro should do: unbundle it. But you're right, it's not that simple to strip ffmpeg from the source tree. Here is a script I hacked up for that purpose.
Ok seems to work but it will be fun to execute this everytime in ebuild (live ebuils) :)
I haven't checked if the ffmpeg/libav ebuild does anything special, but I expect you still lose the ability to play files with more than 20 streams, and MPlayer might break in the strangest ways on any ffmpeg update due to ABI compatibility issues. You also can't expect MPlayer to work with older system FFmpeg and I do not know if everyone is willing to keep they system FFmpeg at bleeding edge. If you want to go this way I recommend trying to cut down on the hacks, e.g. ffmpeg now does install aes.h and sha.h and the internal.h, timer.h and libm.h stuff shouldn't be needed if you remove the HAVE_AV_CONFIG_H from config.h (or remove the timer.h include from the internal.h include).
Ah, vf_pp.c included libavutil/internal.h, for no good reason at all it seems. Got rid of that in upstream SVN, that should reduce the number of hacks by a good bit. And you might change the allcodecs.c comment: If the file isn't there configure refuses to build the GUI. I'm unsure how to fix that in a good way.
(In reply to comment #5) > I haven't checked if the ffmpeg/libav ebuild does anything special, but I > expect you still lose the ability to play files with more than 20 streams, well, yes, but imho this change should be pushed more actively to ffmpeg rather than advertising bundling ffmpeg into mplayer > and > MPlayer might break in the strangest ways on any ffmpeg update due to ABI > compatibility issues. I never understood why mplayer (and some other projects too) people claim this, every program using a shared lib may break if the shared lib maintainer mess up something, this is the responsability of the library authors and, in a distribution, its maintainer. > You also can't expect MPlayer to work with older system FFmpeg and I do not > know if everyone is willing to keep they system FFmpeg at bleeding edge. For now it seems fine with 0.6.90_rc0 ;) > If you want to go this way I recommend trying to cut down on the hacks, e.g. > ffmpeg now does install aes.h and sha.h and the internal.h, timer.h and libm.h > stuff shouldn't be needed if you remove the HAVE_AV_CONFIG_H from config.h (or > remove the timer.h include from the internal.h include). yep, that's what I tried to achieve by submitting the aes/sha.h patch :p
Created attachment 269815 [details] new ffmpeg dumper new version of the dump script, with above comments taken into account and # of hacks reduced. Note to libav maintainers: it now relies on the system libavutil/{aes,sha}.h headers; please push a patch for this in portage and make virtual/ffmpeg-0.6.90 depend on a version providing it otherwise I'll have to make mplayer depend on media-video/ffmpeg
I'm forwarding your patch to expose the crypto api in libav as well.
>> and >> MPlayer might break in the strangest ways on any ffmpeg update due to ABI >> compatibility issues. > > I never understood why mplayer (and some other projects too) people claim this, > every program using a shared lib may break if the shared lib maintainer mess up > something, this is the responsability of the library authors and, in a > distribution, its maintainer. MPlayer uses part of FFmpeg that are not part of the public API. Thus it can break without the library maintainers making a mistake. Yes, that can and should be solved (well, and is mostly solved by disabling certain features) but it's still a bit of a concern.
finally took the time to commit this
There is also a performance loss of about 5% when using shared library vs bundled one. This is critical for apps like mplayer, and yes, this is why mplayer2 is bad for: it is significantly slower, especially on single core system.
