Libav going to be default provider for your codec experience

UPDATE: Added some basic migration instructions to the bottom.
UPDATE2: Removed mplayer incompatibility mention. Mplayer-1.1 works with system libav.

As the summary says the default media codec provider for new installs will be libav instead of ffmpeg.

This change is being done due to various reasons like matching default with Fedora and Debian, or due to fact that some projects which are high-profile (eg sh*tload of people use them) will be probably libav only. One example being gst-libav which is in return required by libreoffice-4 which is due release in about month. To go for least pain for the user we decided to move from default ffmpeg to default libav library.

This change won’t affect your current installs at all but we would like to ask you to try to migrate to the libav and test and report any issues. So if stuff happen in the future and we are forced to throw libav as only implementation for everyone you are not left in the dark screaming for your suddenly missing features.

What to do when some package does not build with libav but ffmpeg is fine

There are no such packages left around if I am searching correctly (might be my blindness so do not take my word for it).

So if you encounter any package not building with libav just open bugreport on bugzilla and assign it to media-video team and add lu_zero[at]gentoo.org to CC to be sure he really takes a sneaky look to fix it. If you want to fix the issue yourself it gets even better. You write the patch open the bug in our bugzie and someone will include it. Also the patch should be sent to upstream for inclusion, so we don’t have to keep the patches in tree for long time.

What should I do when I have some issues with libav and I require more features that are on ffmpeg but not on libav

Its easier than fixing bugs about failing packages. Just nag to lu_zero (mail hidden somewhere in this post ;-)) and read this.

So when is this stuff going to ruin my day?

The switch in the tree and news item informing all users of media-video/ffmpeg will be created at the end of the January or early February, unless something really bad happens while you guys test it now.

I feel lucky and I want to switch right away so I can ruin your day by reporting bugs

Great I am really happy you want to contribute. The libav switch is pretty easy to be done as there are only 2 things to keep in mind.

You have to sync your useflags between virtual/ffmpeg and the newly-to-be-switched media-video/libav. This is most probably best to do just edit your package.use stuff and replace the media-video/ffmpeg line with media-video/libav one.

Then one would go straight away for emerge libav but there is one more caveat. Libav has split libpostproc library while ffmpeg still is using the internal one. Code wise they are most probably equal but you have to take account for it so just call emerge with both libraries.
emerge -1v libav libpostproc

If this succeeds you have to revdep-rebuild the packages you have or use @preserved-rebuild from portage-2.2 to rebuild all the RDEPENDS of libav.

Good luck and happy bug hunting.

Bookmark the permalink.

32 Responses to Libav going to be default provider for your codec experience

  1. Anonymous says:

    Currently, “emerge libav” reports blockers (at least in my system, due to vlc and xine-lib).
    I found out that “emerge libpostproc libav” instead succeeds.
    Is this the expected way to switch to libav?
    You should probably include this (or a better way to switch) in the post.

    • scarabeus says:

      Good point I will add the switch command here :-)

      I was planning it for the news item and totaly forgot on it for the blogpost…

  2. infirit says:

    All nice but this is not for people running stable. systems.. It wants to upgrade gstreamer to 1.0 which is still marked ~amd64….

    • scarabeus says:

      Why should it require gstreamer-1.0? gst-ffmpeg:0.10 works with libav. Or you are trying to install the gst-libav which i just mentioned because it is next evolution of the gst-ffmpeg?

      You don’t need the gst-libav for now. Just the libav :-)

  3. Leifbk says:

    media-video/mplayer still insists on pulling in ffmpeg.

    • scarabeus says:

      I wrote this in the post mate. Just migrate to mplayer2 if possible.

      • Leifbk says:

        Sorry, didn’t notice that. I wasn’t even aware of mplayer2.

        • Anonymous says:

          mplayer2 is not a continuous development of the next mplayer release, it is a fork

          • scarabeus says:

            I said nowhere it is new version. It is obvious that it is different package as they have both different names. I just said it works with external libav properly.

          • Leifbk says:

            Whatever. I seldom use mplayer as I prefer vlc for video watching. But in order to show some video types, Firefox needs gnome-mplayer which depends on mplayer. It seems to work with mplayer2 as well.

      • F_Philipp says:

        What if I cannot migrate and like to have both mplayer1 and 2? Will ffmpeg be supported in the future? Is there a chance to lift the block?

        • scarabeus says:

          Ffmpeg will be supported in the future unless it will became too hard and no developers will be interested. So far Alexis is doing good job so it stays well put.

          Mplayer1 hard-depends on ffmpeg and there is nothing much to do about fixing it apart from making it build with internal ffmpeg again. Upstream won’t include any patches that make it build under both libav and ffmpeg so there is no easy way how to make it build with libav for now. Maybe upstream will change its mind or somebody will be willing to maintain patchset to mplayer1 that makes it work with libav.

    • scarabeus says:

      Updated the in tree ebuild and mplayer-1.1 will build with system libav (0.8, 9 needs more love).

  4. Ewoud Kohl van Wijngaarden says:

    I noticed firefox with USE=gstreamer still pulls in ffmpeg. Is this somewhere on the roadmap or should I file a bug for it?

    • scarabeus says:

      That should not be the case, firefox pulls gst-ffmpeg, which can use libav. So maybe some useflag mismatch why it tries to force ffmpeg on you?
      I would recommend asking on forums with the emerge output.

      • Ewoud Kohl van Wijngaarden says:

        It was the missing libpostproc which caused gst-plugins-ffmpeg to pull in ffmpeg again.

        • scarabeus says:

          Great, good that I added it to the instructions then.

          Maybe we could split the postproc from ffmpeg package too so they are the same and does not cause confusion.

  5. Ondrej Grover says:

    I don’t want to sound like a troll, but sooner or later people will start asking if the switch has anything to do with some gentoo devs being involved in the libav team.

    I’d like to suggest that there should be a somewhat official page somewhere (and a link to it in the GLEP 42 news) disclosing that this decision was made based on a feature comparison (in which case that page should contain such a comparison or at least a link to some up to date article comparing ffmpeg vs. libav) and with having future software compatibility and the best possible gentoo experience in mind and wasn’t “forced by some libav faction”. You know, just to keep people cool.

    Possibly there could be also a few hints about which media player (mplayer, mplayer2, vlc) has the best chance of surviving and becoming a standard in regards to this library turmoil with some explanation. This would be of course a lot harder to say in an unbiased way, but people may start wondering whether it’s a good idea to continue using mplayer or not.

    We already have libjpeg, xorg-server upgrade guides, I think there should also be a page like that for this move. A centralized source of information would prevent users getting confused and angry over inconsistent documentation and reasoning.

    • scarabeus says:

      Well thats why it is me who is announcing everything and doing the work. Because I am not involved in the libav team.

      In the news item there will be explanation about what the hell is going on (eg features xyz, used by abcd …). There seem to be some fuzz at least on 4chan that we are going to remove ffmpeg in favor of libav, which is totaly wrong, we just switch default implementation. Also we still work hard to make stuff work under both libs.

      Well media-player fight is weird, problem with mplayer is that they don’t want to include compat layer to build with libav while mplayer2 build with both of the libs. Mplayer2 on other hand does not contain mencoder which is killer feature for some (altho you can script your encoding needs using libav/ffmpeg directly). But to put this to some rest, we can actually go few steps back and bundle the internal ffmpeg for mplayer1 again as it was done for quite few years before we tried to unsplit.

      Hmm rather than guide we will probably create wiki page, or even better you can start one on wiki.gentoo.org starting to add caveats and steps you had to encounter while migrating.

      • Ondrej Grover says:

        I’m glad you’re being smart about it.

        IMHO, the optimal outcome would be if mplayer1 could have the bundled ffmpeg controllable by a USE flag and that there would be some eselect modules for controlling virtual/ffmpeg and virtual/codec-base. This differentiation of virtuals could also clear things up.

        A wiki page sounds fine, as long as it will be the central and authoritative source of information and will be referenced everywhere.

  6. spinfoam says:

    At first I was not favouring any of the two (ffmpeg or libav) and willing to go the default way. But after a bit of digging around the internet I am now quite in favour of ffmpeg (initially I wanted to post some links and reasons, but it is better for those interested to find themselves).

    The additional reason is mplayer1 which gives me better experience then mplayer2 overall.

    So I would prefer to have both in tree and let the packages building against both to select via useflag. And those that build only against one will have fixed dependency. I am sure it can be done, but I also know it is a lot of work potentially. On the other hand, there is no reason to automatically follow other distros and concerning important projects – mplayer is really such. And where else should one maintain choice then in gentoo?

    • scarabeus says:

      Well mplayer1 is now at least settled due to amount of your crying i took some time to ensure it builds with libav for now.

      Choice is what we try for, but always the choice can be too much burden in some cases and we get rid of some things. This ain’t the issue with ffmpeg tho, it stays, just default is switched and we will recommend the switch to users, but you will still get the same experience (at least i hope that we manage to do so as this library is not something easy to manage :-)).

      BTW: if you wanna chat about it to get more info in CZE just write me on irc or drop me mail :-)

  7. Alexis says:

    Where does this gst-libav is libav only claim come from ? It’s the second time I see it but didn’t find any evidence of it. Due to ffmpeg merges and efforts to be API and ABI compatible with libav, I’ve yet to see a package being libav only.

    OTOH, you should mention xbmc, which will not work in its current state with libav. xbmc-12 being feature frozen will have to be patched. To be honest, I don’t know to what degree. xbmc needs to do audio resampling, I’ve made sure it works with both ffmpeg’s libswresample and libav’s libavresample (for the history: xbmc was using some internal symbols, those symbols changed on the libav side which in turn got merged in ffmpeg and that’s why I made it use the public API); but this means it requires libav-9 (libswresample is in ffmpeg since the 0.10 series), which was not even close to be released at that time, so I didn’t want to spend time making it compatible with such a moving target. I fear the libavfilter usage in there will be a pain.

    Also, I hope this will change in the future, but so far I’ve seen better reactivity from the ffmpeg side than the libav side w.r.t. security issues, which you did not mention at all in your post and users deserve to know.

    • scarabeus says:

      I am almost finished with the resampling stuff, i have some problem with internal lib builds i plan to sort out next weekend and then it will be sorted (which i hope will still be before release).

      The security issues you mention are quite questionable. As I work at SUSE and deal with maintenance stuff the ones you posted are simply crash bugs, which lead to trivial sec issue. So even if you would report these they themselves alone would not mandate any maintenance update.

      Also when I checked the fix in both libraries it seems that ffmpeg just fixed one failing sample after another, where libav rather rewrote the underlying layer fixing the issue for good. Which means that ffmpeg still can pose issues under some samples while libav should not.

      • Alexis says:

        You mean gst-libav will use libavresample ? ffmpeg has it too.

        As for the sec. issues, you’re probably right for some cases, but this means that ffmpeg will have a quick fix neutralizing the vulnerability (or at least part of it) and will then get the right fix with the merges from libav. I don’t consider that bad.

  8. Anonymous says:

    Umpfs – users should be warned that with “+test” a nadditional 423 MB fat file is downloaded…

    • scarabeus says:

      Hmm, where? In pkg pretend? It contains various video samples, thats why it is so huge.

  9. Pingback: FFmpeg vs libav: A distribution maintainer point of view almost two years after the split. « Alexis Ballier’s blog

  10. Vladimir says:

    New LibreOffice-4.0.0.3 cannot import or play multimedia files (like short movies in Impress presentations, for example). It pulled gstreamer-1.0.5 as a dependency and for this reason it needed a new set of gstreamer plugins is I get it right. So I installed gst-plugins-libav-1.0.5 as well, but still have no ability to insert any movie or sound into my LO documents. What else could be wrong?

    Thanks!

    • scarabeus says:

      Whoops. I completely missed this comment requires approval. Sorry for that :-)

      Anyway I see some reported bugs about it, but I didn’t get around yet to try it on Gentoo. So I will do it when I get some free time to see how does it cope.