So the community and the projects both split, and both fought about being the real one. And at first, ffmpeg focused only on features, regardless of code quality, while libav focused on clean code, even if that meant compromising on features.

Obviously, people who aligned with the project lead, and people wondering why stuff suddenly didn’t work anymore, were fed up with libav. Even though it was a situation where libavs codebase was, compared to ffmpeg, much cleaner, similar to openssl vs libressl, but sacrificed a huge amount of functionality for that goal.

EDIT: Rephrasing for accuracy

[0] http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html

https://lwn.net/Articles/650816/

> The project lead had a fight with all the other core contributors

There was longstanding animosity between the project lead and other developers, due to a variety of reasons, mainly his dictatorial leadership style.

> everyone but the lead left the project and forked into libav

A small set of contributors with technical control over certain infrastructure removed the lead's access.

> So the community and the projects both split, and both fought about being the real one.

This contradicts your previous claim that "everyone but the lead left the project".

> And at first, ffmpeg focused only on features, regardless of security, while libav focused on security and clean code, even if that meant compromising on features.

This is ridiculous. libav did remove a large amount of code that was working, some of which may have been insecure or not designed well, but a lot of which was actually necessary for people's workflows and not "dead code" as they claimed. Moreover, ffmpeg had a significantly better security profile than libav due to actually patching bugs rather than waiting to do it right (which ffmpeg developers will argue was basically "doing it differently than ffmpeg").

> Even though it was a situation where libavs codebase was, compared to ffmpeg, much cleaner, similar to openssl vs libressl.

It wasn't cleaner, just less. It became more and more "less" when ffmpeg gained new (well-designed) features, and libav refused to merge them just because they were not designed by libav.

> At the same time, ffmpeg merged pretty much everything, even if that lead to worse code, or security issues.

Do you have proof of this claim, especially for "security issues"?

> That’s nothing different from what I said, I just tried to phrase it more nicely.

Your phrasing makes it sound like the project lead was the instigator.

> FFmpeg is one of the buggiest and most broken collections of code on this planet.

Again, do you have proof of this? I'll admit my experience with ffmpeg is minor, but it seemed like a fairly normal software project when I worked with it rather than a buggy mess.

https://alioth-lists.debian.net/pipermail/pkg-multimedia-mai...

I believe every major distro that jumped to libav has switched back. Some appearance of bias may be just a statement of fact. ffmpeg frequently merged changes from libav, but not vice versa. The newly commissioned (around the time of the fork) library libswresample for example was never brought over to libav, despite being far more ergonomic than libavresample.

Fixed that

> Again, do you have proof of this?

Most media code is already a huge bunch of a buggy mess, and more obscure codecs are usually the worst examples of this. Which is why gstreamer splits the codecs into groups based on how well they are maintained and how clean the code is.

If you read the CVE lists for ffmpeg, you’ll notice that a lot of them are in not so well maintained codecs or functionality (often in parts libav threw out, which annoyed the people who needed this), or in parts where ffmpeg reinvents the world.

It’s a common issue in many projects, and especially in the media world with obscure codecs which often only a handful of people — or only one person — even understand anymore it’s a major problem, and just like with OpenSSL/LibreSSL, it’s a good reason to rip this code out.

ffmpeg was known for overly strict code reviews before the fork, but afterwards Michael N. (the lead dev) merged every single libav commit back in without review and called it weird names like "Qatar" he thought were funny.

To be fair he was also schizophrenic and hallucinating. Good coder though.

> Your phrasing makes it sound like the project lead was the instigator.

He was quite difficult to work with, for instance you couldn't get him to delegate anything, and he wouldn't localize ffmpeg because it would take a few extra CPU cycles to look up strings in language tables.

I haven't been able to look at the project in a while but he's probably better.

ffmpeg has a lot of areas where the cold is old, barely maintained, and has many issues. Have you tried running ffmpeg through a static analysis tool? the resulting warning list will be so large, it wouldn’t fit on a floppy.

libav’s first action was removing such unclean code, which was a good thing, the project started with a good motivation, similar to libreSSL — they also ripped out 90% of working code to clean the codebase up.

> why did libav implement new ffmpeg features in gratuitously incompatible ways? > why did libav print the hilariously defamatory "FFMPEG IS DEPRECATED" message?

Humans are humans, and tribalism is everywhere. After such a fight, usually the groups both declare the other side wrong, and do everything in their might to make their position more popular. That’s not saying it’s justified, and I won’t make a judgement on these actions, nor am I going to declare which side was good or bad, just that libav started with some good ideals, before this happened.

Man, if these reads like ad hominem, I wish you could read the whole story. The linked comment is admirably restrained to the point it prefers being confusing over explaining what happened (fwiw I have no dog in the fight, was privy to the goings-on because my project depended on ffmpeg)