It frankly frustrates me that Debian/Canonical ever used libav to begin with. ffmpeg is and has been the better of the two for quite awhile. The person in this thread arguing against inclusion of ffmpeg would probably be astonished by the number of developers who are building ffmpeg from source instead of using the libav that ships with Debian/Ubuntu/etc. We should encourage developers to use RPMs, especially for something as heavy to build and install as ffmpeg/libav. Many heavy hitters have settled on ffmpeg. It should be done here as well.
I don't think the decision was as obvious from the beginning as you're suggesting. Today, it seems rather obvious that ffmpeg has a much higher development rate. When the fork first happened, libav got a pile of development that made it appear much more active than ffmpeg.
With 20/20 hindsight, sure, Debian should have gone with ffmpeg. But that was not obvious at the time. From the outside, the ffmpeg/libav split looked a lot like the XFree86/Xorg split, where the people doing the work and the people with commit access were too disjoint.
It's also not at all obvious why the libav developers would choose to ignore the work on ffmpeg, while the ffmpeg developers have pulled in changes from libav. From the outside, that decision seems crazy.
There's also the fact that pre-fork FFmpeg was incredibly dysfunctional. I fully expected Libav to pull ahead very quickly due to that there were a lot of real problems with how FFmpeg operated. However, post-fork FFmpeg ended up also mostly resolving those problems (both because there were fewer developers involved that refused to work together, and because MiNi started doing a much better job as maintainer), which I don't think anyone expected.
> It's also not at all obvious why the libav developers would choose to ignore the work on ffmpeg
They have pulled in some things from FFmpeg, but avoiding having to work with some of the FFmpeg developers was one of the main points of the fork. Pulling in all of Libav's changes has been a continual source of pain for FFmpeg and they've talked about halting it a few times, but it is ultimately the reason why FFmpeg is so far ahead in features now.
It was crystal clear within 6 months of the fork. Additionally, the fork itself was an attempted hostile takeover - with git "push -f" (or equivalently, pointing to a different server with a different history), and other lousy stuff. If you were following development weekly, it became clear within 3 months or so.
The main reason debian (and hence ubuntu) packaged libav instead of ffmpeg is that one of the libav guys is also a debian guy.
The libav guys apparently had genuine criticism about ffmpeg development that they felt were not addressed within the prevailing ffmpeg development model at the time -- and thus they had to fork. For all I know, (as an involved user), they were completely right, and perhaps ffmpeg would not have been as good as it is today had they not forked.
However, neidermeyer et al seemed to have responded to the fork with a significantly improved development process. before libav, ffmpeg improved slowly, and tended to reject contributions. Since libav, ffmpeg is improving rapidly, and when code is contributed, they bring it to their standard rather than rejecting it for not living up to it.
Yeah, I agree with this. I think when I posted this I was fairly caught up in my ongoing frustration with this issue. That being said, I'm a developer in my 20s. I wasn't around when a lot of this was actually happening. For the most part, I've relived it through mailing lists and blog posts over the 3ish years I've been an avid user of ffmpeg. I think that tends to skew my historical perspective unfairly. In other words, the perspective and history is very much appreciated.
IMO, the worst part is that they added a ffmpeg 'compatibility' shim that claimed ffmpeg is deprecated. Disgusting behavior. Almost made me dump Ubuntu from all our servers... especially since we use ffmpeg (after playing with both most quickly realize that the real ffmpeg is superior).
"would probably be astonished by the number of developers who are building ffmpeg from source"
Its a do-ocracy and if it took two or so years until Andreas packaged it up, I'm not thinking the claimed demand actually exists. All those devs going to all that work to compile ffmpeg, and yet none of them could be bothered to run dpkg-buildpackage... nah just not seeing it.
There's a relevant line from the post "No, there is no need to replace anything as long as it is maintained." This is why ffmpeg was gone for quite awhile, no one willing to maintain it.
(edited to add, if its not entirely clear, this was totally a bottom up decision not top down, at least as I see it. Not "Debian decided this and that" but individual devs didn't want to package ffmpeg, so it didn't get packaged. That simple. Of course there's social aspects so simple things are never entirely simple... If you want an example of something in Debian being forced top down via general resolution votes and the like, look no further than the systemd debacle)
The debian package maintainer of ffmpeg was/is one of the libav guys and decided to replace ffmpeg with libav.
Judging by several frustrated comments in this thread, it has obviously been a hurtful decision.
> none of them could be bothered to run dpkg-buildpackage
A quick google search shows that lots of people ran dpkg-buildpackage and even put their results up for download.
It sounds like you're surprised nobody tried to upload them... Well, maybe it's not surprising that nobody wanted to get embroiled in another Debian developer power struggle?
> "would probably be astonished by the number of developers who are building ffmpeg from source"
> Its a do-ocracy and if it took two or so years until > Andreas packaged it up, I'm not thinking the claimed demand actually exists. All those devs going to all that work to compile ffmpeg, and yet none of them could be bothered to run dpkg-buildpackage... nah just not seeing it.
I have only been using ffmpeg for 8 months for quick track mixing so I don't know much about its history but going on ffmpeg.org always led me to some ready to use and out-of-the-box binaries hosted there http://ffmpeg.gusari.org/static/ so I don't really see the need for a deb package. (unless the environment is minimal and many lib are missing ? I don't use minimal debian anymore so there's that). Am I missing something ?
Technically, no. But recall that there are many packages that build on libav* or libsw* that could/should also be on ffmpeg which is, as noted elsewhere in this discussion, a safer, more capable build.
Note that most ffmpeg builds are NOT redistributable due to licensing issues - using common libraries like the best AAC encoder available (FDK-AAC) will make your FFmpeg build unredistributable due to licensing issues.
I don't think you can jump to that conclusion. It's fairly easy to get ffmpeg installed without official Debian support, after all; there's no need to reach out on StackOverflow or mailing lists, where such demand could be measured.
Anecdotal data point: In my last two companies, we installed ffmpeg through custom-built packages. Libav just isn't an option.
Did you note the part where I said I "usually use CentOS"? Also the part where I said, "I didn't have a choice" I was stuck using Debian, and hence had to compile from source because someone technically incompetent decided to select avlib instead of ffmpeg.
People are don't read/pay attention are so frustrating.
Nice doc, I didn't knew this sad story. I've engineered with ffmpeg and was impressed with it, it's a technical open-source feat to me, the pied piper fictional hacker comes to mind. How bad we lack a single lead for the API, I now wonder if this explains that no more modernization hadn't gone to the interface.
A package called "ffmpeg" has been in debian forever now, and running it's binary claims that "ffmpeg is deprecated", which is a complete lie.
EDIT: also see "FFmpeg and a thousand fixes" [1], suggesting that FFmpeg is working hard improving the security situation, while libav mainly ignored the effort.
"it's binary claims that "ffmpeg is deprecated", which is a complete lie."
I hadn't been keeping up with ffmpeg development or the debian packaging scene, so that message caught me completely by surprise and threw me for a loop. I spent a good 10 minutes on google trying to first figure out why ffmpeg was being deprecated, and then trying to figure out why debian was lying to me.
"and running it's binary claims that "ffmpeg is deprecated", which is a complete lie."
Ubuntu as well. That immediately made up my mind never to use libav. Incredibly unprofessional since 90 seconds of googling turned up the fact there was a fork and a dispute.
> Although we don't agree with everything FFmpeg does, and we like some of Libav's general goals and development directions, FFmpeg is just better from a practical point of view.
> It shouldn't be forgotten that Libav is doing significant and important development, but since everything they do ends up in FFmpeg anyway, there is barely any reason to prefer Libav over FFmpeg from the user point of view.
> It's also possible that FFmpeg agrees faster to gross hacks to paint over bugs and issues than Libav, however, in the user's perception FFmpeg will perform better because of that.
Basically libav is doing things in the proper way but slowly, so they will die because FFmpeg ships more features although less polished. "The ones that win are the ones that ship", isn't it?
About time. I'm usually all for forking and variety, but libav truly was an example of those gratuitous and destructive forks that offered no real benefit. Though, ultimately, it was the Debian package maintainers' decision to spread propaganda about ffmpeg being deprecated that was the worst.
As a practical example, I was gridlocked when I tried to compile LightSpark from Git, due to libswresample not being present, nor practically obtainable. Editing it out from cmake, predictably, lead to breakage.
The biggest advancement that libav brought was forcing the ffmpeg maintainer to get off his ass and actual lead the project. Shit would still be stagnant if libav didn't come around.
When people say "gratuitous and destructive forks", they aren't referring to the fact that a fork was made, but the method that was used. Instead of cleanly making a new fork, they tried to take control of ffmpeg itself, making the situation worse for all. They also perpetuated a rumour that the ffmpeg project was dead, when it clearly wasn't. Often just the fact that you make the fork is enough to revitalise the development of the original project, or it will stagnate naturally as people use the fork.
As a recent example, no one has tried to take over openssl's development. A number of "fixit" forks have been made, and either openssl will lift their game, the forks will diverge, or they'll be merged back together.
Forking is not that much a problem when it's limited to a program. Typically in the case of MPlayer, you had mplayer2, and nowadays mpv, and this is fine really. It's just a program that could live with the others without much trouble.
On the other hand, with a project like FFmpeg which actually provides libraries, it can really hurts the users community. Especially when the forking is made without changing the library names... which is exactly what happened here (thanks to the confusing name of the fork, chosen on purpose).
Basically, the fork was made such that only one can survive (example: only one "libavcodec" can exists), because they were actually confident about the outcome. But it seems they didn't anticipate such fundamental changes in the way FFmpeg continued to live.
It's about time. I was just using ffmpeg today, wanted libx264 lossless encoding, noticed the deprecation message and lack of libx264 support in the Ubuntu package, recompiled from source.
As someone who regullary had to help people use ffmpeg on #ffmpeg/Freenode, explaining why Debian/Ubuntu packages wrong piece of software under "ffmpeg" package was becoming really tedious.
I've been using ffmpeg packages from deb-multmedia.org repos through the entire libav period. I'm surprised to hear so many people were going through all the trouble to build it themselves.
Bringing back FFmpeg is very important point to people like myself that need lots of tools for video/audio work. Building from source works... but why make life harder?
For Ubuntu 14.10, Debian imports will be frozen in a couple of weeks. So probably it won't make that release, but will be available in 15.04. That's being available in universe. Somebody might put it into 14.10 backports, as well, but that would only affect people technical enough to get ffmpeg anyway. Being used by default would be at least another release on from that, if ever.
That's assuming normal release practices. It could change a bit if Canonical decided to push it, or if a showstopper bug turned up in libav.
Based on the mailing list exchanges this sounds like a fairly contentious topic still. It's possible it will happen, but maybe not for another few releases.
