Libav

Probably you already know that my side of FFmpeg got forced to rename itself to Libav. Some people is still wondering why we did that, you might read some short and longer summaries, have a look at our git or our mailing lists to see how we are faring and where we are heading.

So far I’m quite happy with what we are achieving little by little and day by day: a shared and quite defined plan for the future of the library, releases being a first class citizen, long standing issues being tackled and solved.

We were sorely lacking in the communication side and now we are trying to improve there as well. (This blog post and the website work is just part of it)

In the Gentoo land Scarabeus helped me adding libav, now it is pending some migration work to have all the software working with both libav and ffmpeg.

I hope you’ll be pleased by the outcome (people longing for the multithread work being fully merged I think are).

10 thoughts on “Libav”

  1. Is there any communication about the decision to use libav the MPlayer snapshot and -9999 ebuilds, or to default to libav for virtual/ffmpeg (this one has been reverted, but it is apparently intented to be very temporary…), so soon?

    I wanted to decide by observing April/May activity, when things will have calmed down a little bit, and by following the decision of MPlayer maintainers (although they seem to have some internal conflicts too), but it seems I won’t be able to decide for myself, without having to modify ebuilds manually… :/

    1. We are going to fix the various ebuilds and let you decide what to pick, being it mplayer2, libav, mplayer or ffmpeg. I’m obviously biased in this regard and that’s why Scarabeus prepared and managed most of the virtual setup and I suggest to join our irc channels (#libav and #libav-devel) and mailing lists.

      1. Meaning the MPlayer snapshot and -9999 ebuilds will be able to use FFmpeg again? (of course, if upstream could fully support using a shared ffmpeg, it would be easier).

        And who will decide which to use by default? libav was pushed so soon as default for virtual/ffmpeg… It was reverted a few days ago, but it seems intented to be only very temporary.

        AFAIC, I’m still not quite sure on this whole matter. Things have been quite pushy indeed. My own intent was to observe the mailing list/commit activity for April/May, when things will have calmed down a little bit. I hope I will still have a choice to make then (well, if the original ffmpeg is definitively being continued), without having to modify the related ebuilds myself.

        I also wanted mainly to take into account the decision of MPlayer maintainers on which they decide to bundle in the end, but from what I understood, the issue is quite close to them too, and the internal conflicts seem to exceed “mplayer2″…

        Thanks for your post, anyway.

        1. mplayer2 among the other improvements does not use internal symbols, thus builds with any libavcodec/libavformat implementation provided.

          1. I’ve read this, but from what I understand, the MPlayer fork is significantly more minor (although the changes are indeed interesting in themselves) than the FFmpeg one, and I don’t suppose I’ll switch… (well, things are confusing enough for now, anyway…).

            (Sorry about the previous double Anthony/Quentin post, BTW, I thought my first messages didn’t go through…).

  2. Kindly add a blog posting when threading is in/testable; seriously has pissed me off getting occasional stuttering out of my i7 920 doing 1080p due to the sucker being single threaded πŸ˜‰

    1. It is a bit strange, still h264-mt is currently being fixed and refined since there are still many corner cases breaking it badly

  3. And i really hope when the time comes we’ll also have detailed ffmpeglibav migration guide written down.It could be done in the new official gentoo-wiki infrastructure πŸ™‚

Leave a Reply

Your email address will not be published. Required fields are marked *