I'm not sure why this is posted here, but please note that this was written more than 10 years ago, and a lot of things changed since then. It's important to take this article from an historical perspective, keeping in mind that it was written by someone with "interests" in the matter (as much as I wanted to be objective, let's not lie to ourselves, I was a FFmpeg developer first). The popularity of this article played an important role in "public's opinion" (it's my most popular article ever).
Nowadays, even though I've been distant to the project for years now, I can say the situation changed in a good way (from my perspective). The projects are unified again because people from both sides made difficult compromises. I think it would make sense to focus on how the issue was resolved rather that why it was so bad. This fire is extinguished, let's work on keeping things as peaceful as we can.
For the record, I mostly left FFmpeg development years ago. And while it wasn't the only factor, the merge effort and overall tension actually drained me pretty badly at that time. Of course, this is also true for several people from both sides, and surprising to no one the project(s) lost many developers in the process.
The multimedia community is plagued with drama like this, but this one was particularly destructive. We can certainly take lessons from this, but I'll leave that to the historians.
My biggest takeaway from this fiasco was when a repo maintainer (he was libav) changed ffmpeg to libav in the Ubuntu (or was it Debian?) repositories.
That was a lesson that distros and their repositories are walled gardens just like the various application stores over in the mobile world, curated strictly at the whims of certain individuals or organizations.
It gave me a newfound appreciation for the "just find, install and run whatever whenever wherever" gung ho attitude found in Windows (and to a lesser extent MacOS and Android).
Many people (myself included!) were first amazed by how easy and how much software was @ “just there” for Linux - and apt-get or rpm or emerge and you have what you want.
It’s much later that you realize that someone is doing the work to keep those working, and decisions are being made all the time about which version, which project, etc.
The one I first really noticed was MySQL being silently replaced with MariaDB.
It's too often the software from Ubuntu or Debian repositories is outdated.
For example, Python, Docker, Rust, ClickHouse, Go, and Node.js - all have some versions in Debian, but the common knowledge is to ignore them and always install the official version instead.
It depends on what you want to do. If you want to set up a system and let it maintain itself, stick with the repository version. Upstream versions tend to allow breakages and major version upgrades that make running standard system updates a chore.
Upgrading Node is especially annoying because once you upgrade the default Node binary, you can never get repository software that depends on Node to run reliably again. Everything needs to be installed through NPM from that point on or you'll inevitably get compatibility errors. That also means that you need to change your update procedures, because security and stability updates are no longer taken care of automatically, and that means reading the docs of all the packages you update to look for breaking changes.
If you're doing development, grab the latest upstream versions. They've probably got more features you want, at the cost of having to do the occasional config/setup update.
If you want the latest of the latest of everything, you'll want to switch to something like Arch (or its derivatives) or set up a system separating the upstream tools from the system tools.
It's similar to the Ubuntu release cycle: don't run the rolling release on a server, probably don't run the LTS version on your dev machine.
As a user trying to debug commands suggested on internet didn't work because your version of ffmpeg wasn't actually ffmpeg was kind of insane. And that might be because other applications assumed that "ffmpeg" wasn't something else.
I agree with your sentiment but this is one step further, more akin of active sabotage. How ubuntu just went along with this is beyond me.
The thing I most remember about this piece of history was that Debian, if you told it to install ffmpeg, barfed a message which said "ffmpeg is deprecated, you should switch to avconv".
I knew that wasn't true, and it was pretty insulting to be so brazenly lied to like that. It degraded my opinion of the Debian distro several notches.
(Also, remember when the version of the Bitcoin client in the Debian repo contained hardcoded addresses of several gambling sites which it prevented you from sending to? I think it was pretty clear that Debian maintainers had a lot of power, and sometimes abused that power.)
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.
I wish this post went further back and outlined Fabrice Bellards involvement in ffmpeg - his website says only "FFMPEG, the Open Source Multimedia System. I launched this project in year 2000 and led it for several years. " - I'd be curious to know more about that part of the history.
My only helpful use of chatGPT was "How do I shrink this video and make a thumbnail using ffmpeg..." with some specifics. Definitely flags in there I'd never think of.
I asked ChatGPT for an example to work in memory instead of ffmpeg with files and it just went on and on... plus the dependencies were pretty clearly most at home on Linux.
Writing against the ffmpeg c API is very very unpleasant. The official guidance you'll get is to read the source code of the command line app and copy what it does. This is not at all the normal use case. I would guess GPT will give you horrible advice here because it generally can't help with obscure APIs.
I've found the opposite to be true; the FFmpeg C API is pretty straightforward, although it tends to change a bit since the developers are deprecation-happy. The ffmpeg(1) CLI, though… that's crazy! I've mostly understood its model by now, but a lot of things are completely nonstandard and unexpected. (Like: ffmpeg a.mp4 b.mp4 means two output files, not an input and an output. Lots of arguments mean different things depending on whether they come before an input and an output argument; and yes, that's before and not after. And so on.)
if it is just encoding/decoding ffmpeg can go entirely from stdin to stdout IIRC, provided formats support it. So for example it won't work for mp4 output as it needs to seek to write some headers (again, IIRC) when saving it.
Wouldn't it work if you stream the resulting video as a Youtube Live stream?
You would have to set a stream up in the Youtube creator web page, in order to get a streaming key and with it, a full RTMP URL.
Then in FFmpeg, use "-f rtmp://...your target url" as output. Youtube will stream a live video (which you can hide as "unlisted") and afterwards, the video will remain in the channel as a VOD.
MoviePy is pretty committed to working with files, and I couldn't quickly figure out PyAV pts/dts for the concat even though the files were all exactly the same format.
I'm not sure why this is posted here, but please note that this was written more than 10 years ago, and a lot of things changed since then. It's important to take this article from an historical perspective, keeping in mind that it was written by someone with "interests" in the matter (as much as I wanted to be objective, let's not lie to ourselves, I was a FFmpeg developer first). The popularity of this article played an important role in "public's opinion" (it's my most popular article ever).
Nowadays, even though I've been distant to the project for years now, I can say the situation changed in a good way (from my perspective). The projects are unified again because people from both sides made difficult compromises. I think it would make sense to focus on how the issue was resolved rather that why it was so bad. This fire is extinguished, let's work on keeping things as peaceful as we can.
For the record, I mostly left FFmpeg development years ago. And while it wasn't the only factor, the merge effort and overall tension actually drained me pretty badly at that time. Of course, this is also true for several people from both sides, and surprising to no one the project(s) lost many developers in the process.
The multimedia community is plagued with drama like this, but this one was particularly destructive. We can certainly take lessons from this, but I'll leave that to the historians.