Just another Gentoo Blogs site

The case of defaults (Libav vs FFmpeg)

I tried not to get into this discussion, mostly because it will degenerate to a mud sliding contest.

Alexis did not take well the fact that Tomáš changed the default provider for libavcodec and related libraries.

Before we start, one point:

I am as biased as Alexis, as we are both involved on the projects themselves. The same goes for Diego, but does not apply to Tomáš, he is just a downstream by transition (libreoffice uses gstreamer that uses *only* Libav).

Now the question at hand: which should be the default? FFmpeg or Libav?

How to decide?

– Libav has a strict review policy every patch goes through a review and has to be polished enough before landing the tree.

– FFmpeg merges daily what had been done in Libav and has a more lax approach on what goes in the tree and how.

– Libav has fate running on most architectures, many of those are running Gentoo, usually real hardware.

– FFmpeg has an old fate with less architectures, many qemu emulations.

– Libav defines the API

– FFmpeg follows adding bits here and there to “diversify”

– Libav has a major release per season, minor releases when needed

– FFmpeg releases a lot touting a lot of *Security*Fixes* (usually old code from the ancient times eventually fixed)

– Libav does care about crashes and fixes them, but does not claim every crash is a Security issue.

– FFmpeg goes by leaps to add MORE features, no matter what (including picking wip branches from my personal github and merging them before they are ready…)

– Libav is more careful, thus having less fringe features and focusing more polishing before landing new stuff.

So if you are a downstream you can pick what you want, but if you want something working everywhere you should target Libav.

If you are missing a feature from Libav that is in FFmpeg, feel free to point me to it and I’ll try my best to get it to you.

Post navigation

5 thoughts on “The case of defaults (Libav vs FFmpeg)”

This is only a consequence of libav developers not caring about FFmpeg but FFmpeg trying to be API and ABI compatible IMHO. We’d be in great trouble if both projects simply ignored each other when it comes to the API.

– FFmpeg follows adding bits here and there to “diversify”
– FFmpeg goes by leaps to add MORE features, no matter what (including picking wip branches from my personal github and merging them before they are ready…)
– Libav is more careful, thus having less fringe features and focusing more polishing before landing new stuff.

I’m interested in these three: Could you please add some links and explanations?

Point 1, nothing much to be said or discussed, it is a fact FFmpeg does add bits and among those public functions.

Point 2, my segmenter and my pulse in support got merged by Michael when they were still a draft in my github, other funny lumps of not so perfectly working pieces of code could be the pink-tinted j2k decoder.

Point 3, we have a strict review process, it is not perfect for sure, but gives us a good layer to avoid a number of mishaps, features are usually discussed and from the people feedback they get refined and improved. Currently we are splitting the dsputil little by little so we could cut down the compile time on multicore systems, make easier convert the asm optimization to yasm for the delight of the poor souls needing to use msvc, and make adding codecs such dirac not a partial hack. It is taking lots of time, but we are making it happen.

I understand you are a libav developer? You state that you are biased, which I appreciate, but could you say in which way to get a clear picture?

I’m so glad there is so much discussion going on, as a user, it makes me feel like the developers actually really do care about the result and how the end user will feel about it. Not common in all distributions.

I am biased since when the split happened took side, you can read my point of view on the Libav website . Everything I stated in this post is in my opinion completely rational, but since I took side it is perfectly possible I’m wrong, I’m not considering something or I have other form of bias.