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.
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)
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.
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.
[+] [-] fndrplayer13|11 years ago|reply
[+] [-] JoshTriplett|11 years ago|reply
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.
[+] [-] craigyk|11 years ago|reply
[+] [-] VLM|11 years ago|reply
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)
[+] [-] toomuchtodo|11 years ago|reply
[+] [-] zx2c4|11 years ago|reply
https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav
It helped me make the decision (for choosing ffmpeg).
[+] [-] jesuslop|11 years ago|reply
[+] [-] birkbork|11 years ago|reply
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.
PPS also i dont like the libav crew
1: http://googleonlinesecurity.blogspot.se/2014/01/ffmpeg-and-t...
[+] [-] Crito|11 years ago|reply
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.
[+] [-] camperman|11 years ago|reply
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.
[+] [-] gioele|11 years ago|reply
> 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?
[+] [-] SixSigma|11 years ago|reply
Worse is better
[+] [-] vezzy-fnord|11 years ago|reply
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.
Here's a classic article detailing the situation: http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
And from the mpv developers: https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav
[+] [-] mackal|11 years ago|reply
[+] [-] ux|11 years ago|reply
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.
[+] [-] picomancer|11 years ago|reply
[+] [-] izacus|11 years ago|reply
So thanks to Debian maintainers to fix stupidity.
[+] [-] mkhpalm|11 years ago|reply
[+] [-] Xeoncross|11 years ago|reply
[+] [-] igravious|11 years ago|reply
[+] [-] danohuiginn|11 years ago|reply
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.
[+] [-] fndrplayer13|11 years ago|reply
[+] [-] VLM|11 years ago|reply
[+] [-] dtparr|11 years ago|reply
[+] [-] giancarlostoro|11 years ago|reply
I'm easily amused.
[+] [-] shmerl|11 years ago|reply
[+] [-] ausjke|11 years ago|reply
[+] [-] shmerl|11 years ago|reply