10 ms·

Reintroducing FFmpeg to Debian

154 points by unspecified 12y ago

fndrplayer13 12y ago
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.
- toomuchtodo 12y ago
  I previously used ffmpeg in a broadcast production environment, and had to compile from source constantly because of this terrible decision.
  - baldfat 12y ago
    You used the wrong Distro :) Redhat or SUSE.
    - toomuchtodo 12y ago
      I didn't have a choice. I usually use CentOS.
      - baldfat 12y ago
        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!
        toomuchtodo 12y ago
        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.
        baldfat 12y ago
        Or frustrating when the sentence is ambiguous.
- VLM 12y ago
  "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)
  - birkbork 12y ago
    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 http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
  - johnchristopher 12y ago
    > "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/ 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 ?
- craigyk 12y ago
  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).
- JoshTriplett 12y ago
  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.
  - beagle3 12y ago
    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.
  - plorkyeran 12y ago
    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.
VLM 12y ago
I wonder what Niedermayer would say / has said.
- dtparr 12y ago
  He's commented a few times on the Debian bug here (CTRL-F): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203
vezzy-fnord 12y ago
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. Here's a classic article detailing the situation: http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html 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 https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav
- mackal 12y ago
  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.
  - keeperofdakeys 12y ago
    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.
- ux 12y ago
  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.
zx2c4 12y ago
Here's a nice comparison between libav and ffmpeg from the author of 'mpv' (the most viable mplayer fork): https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav It helped me make the decision (for choosing ffmpeg).
- jesuslop 12y ago
  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.
birkbork 12y ago
Finally, thank you! 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-thousand-fixes.html http://googleonlinesecurity.blogspot.se/2014/01/ffmpeg-and-t...
- Crito 12y ago
  "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.
- camperman 12y ago
  "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.
  - klodolph 12y ago
    Well, Ubuntu's package maintainers are mostly Debian package maintainers... same goes for Mint.
igravious 12y ago
This'll make it into Ubuntu when? Any estimates out there?
- fndrplayer13 12y ago
  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.
- danohuiginn 12y ago
  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.
ausjke 12y ago
eglibc went back to glibc, now ffmpeg comes back to debian, nice!
- shmerl 12y ago
  Now iceweasel should go back to firefox ;)
  - e12e 12y ago
    Uh, why? It's pretty much just a rebrand (for trademark license reasons). It's not the same as the other two examples.
    - shmerl 12y ago
      Those reasons are mostly obsolete already. But it was never rebranded back: https://bugzilla.mozilla.org/show_bug.cgi?id=555935 https://bugzilla.mozilla.org/show_bug.cgi?id=555935
picomancer 12y ago
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.
shmerl 12y ago
Good, mpv will now get more features.
mkhpalm 12y ago
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.
gioele 12y ago
I think the FFmpeg vs libav debate is succinctly described by this quote from https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav > 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 12y ago
  > "The ones that win are the ones that ship", isn't it? Worse is better
  - dspillett 12y ago
    Released is better.
izacus 12y ago
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. So thanks to Debian maintainers to fix stupidity.
giancarlostoro 12y ago
"I do not believe you, explain that voodoo to me: How is it that it won't break all of Debian and make kittens cry?" I'm easily amused.
Xeoncross 12y ago
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?

154 points by unspecified 12y ago

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.

toomuchtodo 12y ago
I previously used ffmpeg in a broadcast production environment, and had to compile from source constantly because of this terrible decision.
- baldfat 12y ago
  You used the wrong Distro :) Redhat or SUSE.
  - toomuchtodo 12y ago
    I didn't have a choice. I usually use CentOS.
    - baldfat 12y ago
      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!
      - toomuchtodo 12y ago
        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.
        baldfat 12y ago
        Or frustrating when the sentence is ambiguous.
VLM 12y ago
"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)
- birkbork 12y ago
  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 http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
- johnchristopher 12y ago
  > "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/ 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 ?
craigyk 12y ago
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).
JoshTriplett 12y ago
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.
- beagle3 12y ago
  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.
- plorkyeran 12y ago
  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.

VLM 12y ago

I wonder what Niedermayer would say / has said.

dtparr 12y ago
He's commented a few times on the Debian bug here (CTRL-F): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203

vezzy-fnord 12y ago

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. Here's a classic article detailing the situation: http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html 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 https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav

mackal 12y ago
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.
- keeperofdakeys 12y ago
  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.
ux 12y ago
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.

zx2c4 12y ago

Here's a nice comparison between libav and ffmpeg from the author of 'mpv' (the most viable mplayer fork): https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav It helped me make the decision (for choosing ffmpeg).

jesuslop 12y ago
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.

birkbork 12y ago

Finally, thank you! 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-thousand-fixes.html http://googleonlinesecurity.blogspot.se/2014/01/ffmpeg-and-t...

Crito 12y ago
"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.
camperman 12y ago
"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.
- klodolph 12y ago
  Well, Ubuntu's package maintainers are mostly Debian package maintainers... same goes for Mint.

igravious 12y ago

This'll make it into Ubuntu when? Any estimates out there?

fndrplayer13 12y ago
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.
danohuiginn 12y ago
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.

ausjke 12y ago

eglibc went back to glibc, now ffmpeg comes back to debian, nice!

shmerl 12y ago
Now iceweasel should go back to firefox ;)
- e12e 12y ago
  Uh, why? It's pretty much just a rebrand (for trademark license reasons). It's not the same as the other two examples.
  - shmerl 12y ago
    Those reasons are mostly obsolete already. But it was never rebranded back: https://bugzilla.mozilla.org/show_bug.cgi?id=555935 https://bugzilla.mozilla.org/show_bug.cgi?id=555935

picomancer 12y ago

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.

shmerl 12y ago

Good, mpv will now get more features.

mkhpalm 12y ago

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.

gioele 12y ago

I think the FFmpeg vs libav debate is succinctly described by this quote from https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav > 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 12y ago
> "The ones that win are the ones that ship", isn't it? Worse is better
- dspillett 12y ago
  Released is better.

izacus 12y ago

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. So thanks to Debian maintainers to fix stupidity.

giancarlostoro 12y ago

"I do not believe you, explain that voodoo to me: How is it that it won't break all of Debian and make kittens cry?" I'm easily amused.

Xeoncross 12y ago

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?