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.
Comments
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.
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 reality is not like you describe it.
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.
There are a few writeups of the situation on the web, here's one: http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
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?
I've been using ffmpeg from dmo (http://deb-multimedia.org) for a long time without much hassle despite the handwavy claims about how bad they are according to https://wiki.debian.org/DebianMultimedia/FAQ
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.
That’s one of the reasons for lack of builds.
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.
I previously used ffmpeg in a broadcast production environment, and had to compile from source constantly because of this terrible decision.
You used the wrong Distro :) Redhat or SUSE.
I didn't have a choice. I usually use CentOS.
CentOS IS Redhat without a contract and is in fact owned by Redhat since last year.
PS. Everyone that down voted me for saying he used the wrong Distro, he was using CentOS which uses ffmpeg.
Hacker News Down Votes are so frustrating!
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.
Or frustrating when the sentence is ambiguous.