Reintroducing FFmpeg to Debian
lists.debian.org
lists.debian.org
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!
People are don't read/pay attention are so frustrating.
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.
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
> 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 ?
Anecdotal data point: In my last two companies, we installed ffmpeg through custom-built packages. Libav just isn't an option.
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?
That’s one of the reasons for lack of builds.
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.
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.
> 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.
https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav
It helped me make the decision (for choosing ffmpeg).
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...
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.
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?
Worse is better
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
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.
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.
So thanks to Debian maintainers to fix stupidity.
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.
I'm easily amused.