LWN: Comments on "Why Debian returned to FFmpeg"

Why Debian returned to FFmpeg

turbulens — Mon, 19 Oct 2015 12:59:00 +0000

If you see the "About" section on VLC, you'll see they give credit to FFmpeg. They use FFmpeg too. I don't understand your means by "stick to Libav" .

Why Debian returned to FFmpeg

flussence — Sat, 01 Aug 2015 17:56:45 +0000

I'm sure I could go rooting through 4 years of your own project's mailing lists and blogs to dig up similar dirt if I were so inclined.

The point is I don't have to.

Why Debian returned to FFmpeg

lu_zero — Fri, 31 Jul 2015 20:46:40 +0000

http://article.gmane.org/gmane.comp.video.ffmpeg.devel/13... professionally.

http://article.gmane.org/gmane.comp.video.ffmpeg.devel/17... silent.

Main ffmpeg developer now resigned, hoping to reunite the communities

moltonel — Fri, 31 Jul 2015 16:29:47 +0000

http://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/176489...

Thanks to Michael for the work done so far, and for this very mature and diplomatic move. I certainly hope that this'll have the desired effect of reuninting the libav and ffmpeg communities.

Why Debian returned to FFmpeg

gabucino — Fri, 31 Jul 2015 16:15:04 +0000

Out of pure curiosity: when was the last time you (accidentally) spoke the truth?

Why Debian returned to FFmpeg

flussence — Thu, 30 Jul 2015 18:05:44 +0000

If that rigid adherence to process had any correlation to delivering what users want, they wouldn't have spent years fighting to rid themselves of the libav nuisance. So in the end, it's worthless.

Why Debian returned to FFmpeg

flussence — Thu, 30 Jul 2015 18:02:39 +0000

Sure, here's one: https://lwn.net/Articles/652736/

FFmpeg has been professionally silent on public forums. Your side would do well to learn from their example.

Why Debian returned to FFmpeg

lu_zero — Wed, 29 Jul 2015 14:56:00 +0000

This quite slandering statement clashes with the commit statistics touted in the article and maybe you might substantiate such wild accusation...

Every commit in Libav goes under review in the mailing list. At least for the patches that are not single-line fixes, it could take about 24 hours or more before a submission hits the tree.

On the other hand the Libav code gets "merged" in FFmpeg daily w/out any kind of review. The huge amount commits reported on the Michael side probably is inflated by the merge commits.

Why Debian returned to FFmpeg

lu_zero — Wed, 29 Jul 2015 13:54:37 +0000

Please provide links to corroborate your statement.

Nobody in Libav ever discussed FFmpeg beside me on here

https://blogs.gentoo.org/lu_zero/2015/02/20/demotivation-...

Let alone "smear".

On the other side, at least few of the the new people contributing to Libav got quite interesting emails from Michael Niedermayer and Carl Eugen Hoyos. (I can say few since they did ask me what the hell was it about, I have no way to know if ALL the new contributors got this kind of interesting service).

Why Debian returned to FFmpeg

Vesiukko — Sat, 25 Jul 2015 19:19:07 +0000

I know that this comment comes late to this discussion but I wanted to tell libav people something. Please read this blog post since it reflects almost exactly my thoughts on this matter. And it's still fairly accurate description of the situation even after all these years. I'm personally very happy that Debian decided to switch back to ffmpeg. It certainly makes my life a lot easier.

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

Why Debian returned to FFmpeg

riking — Thu, 23 Jul 2015 18:23:22 +0000

> At the same time it seems that every media project is bundling a local copy of FFmpeg because of fundamental incompatibilities even between minor releases. How can both stances be valid at the same time?

In my experience, this has been done because it needed something implemented one way in ffmpeg but implemented a different way in avconv.

Why Debian returned to FFmpeg

jond — Thu, 23 Jul 2015 13:39:24 +0000

> name recognition.

This is a good point.

Before I knew anything else about the situation, I was often surprised to find the following banner printed when I ran the ffmpeg binary on a Debian system:

> *** THIS PROGRAM IS DEPRECATED ***
> This program is only provided for compatibility and will be removed in a future release. Please use avconv instead.

This was puzzling, and misleading because ffmpeg was not deprecated, per se; but the libav implementation of the ffmpeg binary was planned to be removed. This was aa watered down version of an earlier warning:

> This program is not developed anymore and is only
> provided for compatibility. Use avconv instead

Which IMHO was even more misleading.

Why Debian returned to FFmpeg

moltonel — Thu, 23 Jul 2015 11:41:37 +0000

Indeed, the commit numbers of "all libav devs" VS "ffmpeg devs excluding michael and the libav devs" is roughly the same. In other words, if ffmpeg's star commiter disappeared and if ffmpeg stoped merging any libav changes, the commit rate of both projects would become roughly equal (yes, commit rate is a poor metric, but it's still a usefull hint). So it's hard use the bus factor argument against ffmpeg.

Why Debian returned to FFmpeg

flussence — Tue, 21 Jul 2015 20:35:18 +0000

>Even though ffmpeg largely depends on libav for development, ffmpeg has been always badmouthing libav in all kinds of ways. From "they don't fix security issues" to plain old "their code is shit".

Do you have any citations to back that up? Because I've seen libav doing an order of magnitude more smearing, up to and including sending fraudulent legal threats over the logo, claiming ffmpeg "steals" code, distributing a fake ffmpeg scareware binary, posts like yours, and so on.

Regarding security, libav makes regular appearances on the security updates page on this site - often for ffmpeg CVEs dated 3-4 years ago. The opposite has never occurred.

Why Debian returned to FFmpeg

raven667 — Tue, 21 Jul 2015 14:50:32 +0000

This whole line of reasoning is a bunch of baloney right on the face of it, I'm not intimately familiar with the personalities and code between ffmpeg and libav but this is just blatantly wrong.

The "merge everything they make" activity could flow both ways, both projects have the opportunity to merge each others changes, if the policy of merging most of the libav changes into ffmpeg has made ffmpeg a stronger software then it's libav policy against merging ffmpeg changes which has made them the weaker project.

As far as any negative criticism of libav being due to some Internet-wide smear campaign, wow, that justification is basically never right, the universe does not revolve around the petty differences of a couple of folks, I can't imagine that most people who ship either library really cares about the split, they just want something that works, so the idea that a "smear campaign" could gain any traction is laughable. Ha ha ha. This is especially true for Google which is spending their time and money to fuzz test this software, which is an incredible gift, and has real metrics to back their statements, not whispers.

Why Debian returned to FFmpeg

KotH — Tue, 21 Jul 2015 08:14:20 +0000

The way this "hostile" fork has been won, was simply by two things:

1) Merge everything they make.
Yes. ffmpeg merges every and each commit to libav (with a dozen or so notable exceptions in the last 4 years). Which makes ffmpeg actually downstream of libav. This can also be seen in the commit numbers, the top 4 "contributors" to ffmpeg are, beside Michael, people who work on libav and left ffmpeg because of Michael. The huge number of commits Michael has, is largely inflated by the daily merges of libav code he makes, and the many little fixes those merges need.

2) Continous smear campaign.
Even though ffmpeg largely depends on libav for development, ffmpeg has been always badmouthing libav in all kinds of ways. From "they don't fix security issues" to plain old "their code is shit". This has been discussed as the videolan developer days a few times, but were never actually addressed by the ffmpeg developers responsible.

And for those who claim that ffmpeg is better/more secure/whatever, why then does VLC stick to libav, if ffmpeg is so much better?

Why Debian returned to FFmpeg

isilmendil — Wed, 15 Jul 2015 22:17:06 +0000

As far as I understand it, the contributors you listed are libav contributors, not ffmpeg ones. FFmpeg pulls in commits from libav whenever possible, so almost any libav contribution will automatically turn up in FFmpeg.

Why Debian returned to FFmpeg

anselm — Wed, 15 Jul 2015 09:33:13 +0000

So winning in the presence of a hostile fork basically involves not sucking *too* much more than the fork. You don't even have to be better (assuming you had some success before the fork). You just have to be tolerable, and people will likely stick with what they know. So it's not really *that* impressive a feat.

The best example of that is probably OpenOffice vs. LibreOffice. LibreOffice is arguably the better program, but especially on Windows, people will still install OpenOffice because that is the name they know. (On Linux, LibreOffice seems to be more popular because most people get it from their distributions, which for the most part jumped ship from OpenOffice to LibreOffice even before OpenOffice became an Apache project.)

Why Debian returned to FFmpeg

dgm — Wed, 15 Jul 2015 08:37:03 +0000

Careful, some of the most prolific contributors to ffmpeg (Giovara, Storsjö, Khirnov and Cadhalpun are on the top list) are also libav contributors. Maybe you should be talking to them before saying such things.

Why Debian returned to FFmpeg

xtifr — Tue, 14 Jul 2015 21:20:09 +0000

Of course, any reasonably successful project has a built-in defense against hostile forks: name recognition. This is sort of like the incumbent issue in politics; people are more likely to go with the names they recognize, unless there are *strong* reasons to do otherwise. Hostile forks that actually go on to displace the original are rare indeed. The few that do often involve broad community outrage with the original (e.g. Xfree86 v Xorg), or indisputable and incontrovertible success (GCC v EGCS, although that one eventually ended with a friendly merge).

So winning in the presence of a hostile fork basically involves not sucking *too* much more than the fork. You don't even have to be better (assuming you had some success before the fork). You just have to be tolerable, and people will likely stick with what they know. So it's not really *that* impressive a feat.

(If you're going to do it, though, winning over major distros based on technical merit, as FFmpeg seems to have done in this case, is definitely one of the best ways to do it.) :)

Why Debian returned to FFmpeg

flussence — Tue, 14 Jul 2015 17:46:55 +0000

> But, as Reinhard pointed out, there is a bit more to this story. Changes to libav are routinely merged into FFmpeg, but the flow of patches in the other direction is quite low.

It's been stated elsewhere that Libav takes just as much code from FFmpeg too - but they launder it through total rewrites so as to not give credit to the original authors and inflate their own numbers. This is consistent with the borderline-sociopathic mud-slinging they seem to do at every chance they get.

Why Debian returned to FFmpeg

flussence — Tue, 14 Jul 2015 17:30:04 +0000

> Question for the people familiar with FFmpeg: what is the argument against adopting, in addition to the existing API, these new, better designed APIs?

FFmpeg has supported both for a number of years, so the argument is moot.

Why Debian returned to FFmpeg

josh — Tue, 14 Jul 2015 16:17:07 +0000

At the moment, ffmpeg (as real packages and libraries, rather than as transitional packages to libav) only exists in unstable; it is intentionally kept out of testing and thus stable releases. This transition would mean that libav will be removed from testing, and ffmpeg allowed in, with all of the reverse-dependencies of libav rebuilt to use ffmpeg instead.

Why Debian returned to FFmpeg

jezuch — Tue, 14 Jul 2015 06:57:19 +0000

AFAIK (as a Debian user) Debian currently includes both ffmpeg and libav. There are even builds of mpv for both. (I actually have the ffmpeg version installed.)

Why Debian returned to FFmpeg

rsidd — Tue, 14 Jul 2015 05:46:53 +0000

I'm not familiar, but this person is and claims that the libav people "rewrite everything." I.e., not just crufty old stuff, but new features in ffmpeg (he gives several examples) that they could just have lifted, but chose to reimplement in an incompatible manner because they don't like it. (The article is from three years ago.)

Why Debian returned to FFmpeg

xtifr — Tue, 14 Jul 2015 01:26:10 +0000

While Michael's commits are in a league of their own, there are several other contributors to FFmpeg whose contributions, if made to libav instead, would put them in a "major contributor" role. Clément Bœsch, James Almer, and Carl Eugen Hoyos all have more contributions to FFmpeg than all but the top three libav contributors did to libav, and Andreas Cadhalpun is only slightly behind the fourth. Even if Michael were to vanish off the Earth tomorrow, it would seem that those four would only have to pick up their game a _little_ to keep FFmpeg operating at _at least_ the same level of support that libav offers.

(Just an observation based on the data presented in this article. Obviously, not all commits are created equal, and I have no idea what quality of patch any of the folks involved in either project have to offer.)

Why Debian returned to FFmpeg

atai — Mon, 13 Jul 2015 22:37:10 +0000

Michael Niedermayer essentially beats the fork--this is a great example of how to win in the presence of a hostile fork.

Why Debian returned to FFmpeg

josh — Mon, 13 Jul 2015 21:49:47 +0000

ffmpeg's API is a lot less unstable than it used to be. sonames change periodically, but not every single version.

Why Debian returned to FFmpeg

gioele — Mon, 13 Jul 2015 21:03:40 +0000

The discussion thread contains this statement:

> I think the debate on the development methodology is the biggest
> disagreement between the two projects: FFmpeg insists on keeping its
> development velocity and allowing developers to "get work done",
> compromising on maintainability and common understanding of the code base
> in favor of more features. Libav on the other hand rather focuses on clean
> implementation and let's say better designed APIs. This requires more work,
> which in effect significantly lowers the development velocity.

Question for the people familiar with FFmpeg: what is the argument against adopting, in addition to the existing API, these new, better designed APIs?

I read that the FFmpeg maintainer is keen on maintaining the old API around for compatibility reasons. At the same time it seems that every media project is bundling a local copy of FFmpeg because of fundamental incompatibilities even between minor releases. How can both stances be valid at the same time?