Being at the VDD conference when the libav and FFmpeg developers got together in a single room and agreed to come together and elected leadership and stuff was a really cool experience. I knew libav wasn’t really alive but when Diego said “It’s dead” it really hit me that the libav/FFmpeg drama really might be coming to a close finally.
ffmpeg has many internal components (avformat, avcodec, etc) but none of those are “libav”. libav was a fork of all the ffmpeg code (they took all the code, copied it, renamed their copy to libav, and changed the name of some binaries like changing the ffmpeg binary name to avconv). That fork is dead now. No one is maintaining it. The libav.org site doesn’t exist anymore.
It's sad that there aren't any alternatives to ffmpeg. It could have been a mutually beneficial relationship if they dropped the antagonism and uncooperative behaviors. Instead they just essentially killed libav.
It's like saying it would be good if there were two competing projects writing something akin to the Linux kernel. It's just not true. The mutually beneficial thing is to have one project where all developers are happy to work together. This is obviously idealized, but FFmpeg vs. Libav was 10x worse than what we have today. Imagine how Intel or Nvidia would contribute (either to the broken-up Linux or broken-up FFmpeg) new drivers or new hardware codec integration if there was competition. It would be a horrible end user experience.
> It's like saying it would be good if there were two competing projects writing something akin to the Linux kernel.
It isn't even that. ffmpeg and libav were two competing forks of the exact same project, not two distinct projects working to implement the same thing.
> It isn't even that. ffmpeg and libav were two competing forks of the exact same project, not two distinct projects working to implement the same thing.
But given enough time they would become very distinct.
The actual history of the projects doesn't bear that theory out. Aside from the rename itself and a couple of minor API changes, the projects stayed pretty close together, and a lot of patches got copied between the pair.
ffmpeg is a fairly complex project which deals with a number of esoteric topics (audio/video file formats, compression, processing, etc). The number of open-source developers who are qualified to work on it, and who have the time and inclination to do so, is fairly limited; I suspect that there simply isn't a large enough population of those developers to support multiple actively developed projects in this space, and certainly not two as similar as ffmpeg/libav were.
Patches were copied one way, and functionality was deprecated in ffmpeg but the only way to do it in libav (audio.) As someone who was writing software using the ffmpeg/libav apis it was a horrible confusing mess. Since distros were split you had to support both and the each had different quirks. It was a dark time that I'm glad is over.
I don't use intel or nvidia, nor really care if they are only willing to cooperate with homogenius ecosystems. Open source developers seem to treat their own little parts of the stack as their fiefdoms, afraid any competition. Then, eventually, someone figures out they can leverage that position against the user. It's toxic, and for some reason, is heavily promoted by hackernews types. It doesn't hurt anyone if someone works on their own project seperate from everyone else. Anyone that develops code is contributing, no matter where that code goes.
> It's like saying it would be good if there were two competing projects writing something akin to the Linux kernel. It's just not true.
No, I think it actually can be true. For example, since you point out Linux, the world is better for having FreeBSD, because FreeBSD does things that Linux can't (ZFS in-tree) or won't (combined base OS, not just a kernel).
Note that this works when there's a significant difference; if we start with a fork of the exact same code, it'll need a real driver to matter (example: any project acquired by Oracle and immediately forked by the community).
Audio and video codec libraries are among the most complex things there are in the software world, I'd say - even more complex than GPUs because there are only four major GPU vendors/families remaining (AMD, NVIDIA, Intel, PowerVR):
- knowledge about how encoding audio and video works is rare (as it involves a ton of maths 99% of the population won't ever come close to understand), and people not bound by NDAs and thus actually able to work on FOSS projects in that area are even rarer in the first place.
- they have to deal with an absolutely insane amount of different codecs and their "profiles" (aka supported features list) that are all in active use by someone or something (mpeg2 for DVDs and early DVB-T/C/S, h264 for fullhd stuff, h265 for >fullhd, AV1 for YouTube), and all the historical codecs
- almost all of these have some hardware encoders with their own unique quirks which libraries have to take into account to support playback (and maintain that as well), not to mention software encoders in different versions and bugs, or error correction to deal with bitrot or transmission errors
- on top of that, there's a family of container formats - although most have settled on mp4 or (in the piracy world) Matroska, there is still a lot of legacy stuff floating around
- dealing with codecs means walking around on eggshells around laws and patents (DRM, the minefield that are video patents, ...)
- dealing with multimedia files in general means dealing with densely packed and hard-to-parse binary structures, which is a Very Complex Thing To Do on its own and is a constant source of security issues.
- supporting acceleration means even more rare knowledge and dealing with more NDAs or reverse-engineering
- the APIs used to communicate with downstream clients (converters, media players, ...) are decades old grown baggage, and cleaning that up is next to impossible because the ecosystem is all so fractured, which means a ton of effort in implementations and maintenance
Long-term it's infeasible to have more than one open source project... there are simply not enough capable developers around for the workload.
Thing is, it was the libav guys who attempted a hostile takeover of ffmpeg by stealing the domain, then did a hard fork they called libav and pushed it into distros like Debian, lying about ffmpeg being deprecated and behaved in many ways massively toxic. There are walls of summaries from this horrible event.
Mans Rullgard was of the guys leading the toxic mob.
Not the other way around as you are implying.
Source: I was involved in ffmpeg at the time and read their mailing list over those years.
I wanted to take a moment to dispute this rumour regarding FFmpeg and Mans Rullgard, which I believe to be unfounded and baseless.
Firstly, I am proud to say that I have been contributing to the development of the SIMD optimization in the Libpostproc component of FFmpeg, specifically working on optimizing functions to take advantage of SIMD instructions on modern CPUs and thereby enhance performance and as such I have been involved in the FFmpeg community for a number of years.
There have been claims of a potential hostile takeover involving Mans Rullgard. However, I have first hand experience that these rumors are completely false and are nothing more than fabrications by a toxic spinter group within the community who are "gaslighting" the good guys.
In particular I remember but that an individual with a handle somewhat similiar to "aew4ytasghe5" was banned from our community due to repeated rudeness and hostility, and not for any other reason. I am not claiming this is you but it would not be a surprise to me on a personal level.
I hope that this clarifies the situation and puts these rumors to rest. FFmpeg is a community-driven project that thrives on collaboration and mutual respect, and I am proud to be a part of it and it hurts me when I see toxic people attacking open source communities.
JB, when’s the next VDD?