9 ms·

Why Debian returned to FFmpeg

265 points by vezzy-fnord 11y ago

callesgg 11y ago
In almost every use case i have i have, libav has not been able to fulfill my needs and i have had to get rid of libav and install ffmpeg.
- _delirium 11y ago
  Do you have examples? I currently have libav on my Debian machines and ffmpeg on my Ubuntu machines, but haven't really noticed a difference for my needs. I'm not doing anything too complex, admittedly.
  - simcop2387 11y ago
    One that I've encountered is that I had trouble setting up live streaming to youtube with libav. Something weird with the rtmp code, with ffmpeg it worked out of the box. Not sure if it matters that it was on a raspberry pi.
    - icelancer 11y ago
      This was my experience in using ffmpeg with an unrelated rtmp pipe as well. libav caused a ton of very strange and non-reproducible errors that were inconsistent. The switch back to ffmpeg cleaned up 90%+ of the problems.
  - roghummal 11y ago
    Most of what I do with ffmpeg is change containers. Example: ffmpeg -i doom4_trailer.mkv -acodec copy -vcodec copy doom4_trailer.mp4 Pretty simple, right? libav: >[mp4 @ 0xa33800] Application provided invalid, non monotonically increasing dts to muxer in stream 0: -83 >= -83 >av_interleaved_write_frame(): Invalid argument (premature exit)
- pvaldes 11y ago
  Same with me, ffmpeg worked accurately and was extensively documented. Then a day there was no more here. I tried to understand the reasons and adopt avconv despite the ego wars, and those irritant message, and the cumbersome new syntax, and the lack of tutorials in internet... but finally the problem is that avconv just did not worked, and nobody really knew what to do with it. In the end I stopped using both programs. One was aparently unsafe and not installable without breaking things, and the other reinstall itself constantly, acts in a questionable way, and did not solve my problems. I guess that for Debian this was a false step that consumed time and resources but did more damage than good. Libav probably damaged also the image and dominant position of VLC. After several errors and troubles since them, its current luster is not the same as in the first years in my opinion.
wmantly 11y ago
About time, libav has never meet my needs.
wmantly 11y ago
About time, libav has never meet my needs.
andmarios 11y ago
As a Gentoo user, libav only gave me trouble. It was incompatible with many packages, whereas ffmpeg was with none I encountered. The switch to libav was horrific and I never managed to resolve all the issues it created with my system. For some months, updating my system was a herculean task due to libav causing constant —and largely unsolved— trouble. I was really happy to see Gentoo return to ffmpeg. Everything works smooth once again. I can't comment on code quality, project management, etc and frankly I don't care. If one library causes problems to every bit of my system, it should stay off until it is on par with the library it tries to replace —provided that both libraries use a free software compatible license.
- tanderson92 11y ago
  Can't you choose libav / ffmpeg as you see fit on Gentoo machines ?
  - TheDong 11y ago
    Yes. Gentoo changed the default profile's use flags to include "libav", but adding USE="-libav" would get you back to the ffmpeg world. Gentoo has supported both for as long as its included libav at all.
  - TheDong 11y ago
    Yes. Gentoo changed the default profile's use flags to include "libav", but adding USE="-libav" would get you back to the ffmpeg world. Gentoo has supported both for as long as its included libav at all.
  - andmarios 11y ago
    Νear the end of 2014, libav became the default library. Until then it was up to the user to choose, so most of us were with ffmpeg due to our old use flags. Given the new status quo, my system refused to update since it would pull both libav due to the new profile and ffmpeg due to my use flags. As the Gentoo devs made this new choice, I thought I should embrace it, so I followed the steps to switch to libav. This created a nightmare of dependency issues that took me months to solve, especially given my limited time and that this happened on my main machine. I finally switched back to ffmpeg but it seemed to me that only when it —libav— was removed from Gentoo's default desktop profile my problems really stopped.
zimbatm 11y ago
Michael is just amazing. I once had a bug with ffmpeg which he helped me pin down on IRC and then produced a patch for it immediately. I was disappointed of how aggressive the libav guys where during the fork. They changed the content of ffmpeg.org (which they had legitimate access to) to claim that libav was now the new name of the project. Then they replaced the ffmpeg package in Debian with their own version. It's entirely possible to maintain both packages in Debian with the alternatives framework. This whole false dichotomy and calling ffmpeg the fork is not helpful in my opinion. So I'm glad that ffmpeg is getting it's package back. Forks are good and should stand on their own merit instead of doing politics like that.
- camperman 11y ago
  When I was told that ffmpeg was deprecated by libav, I immediately checked whether this was the truth. It wasn't. Bye bye libav - forever. Don't ever lie to your end users.
  - plorkyeran 11y ago
    The libav version of the command line tool named "ffmpeg" was in fact deprecated and has since been removed entirely. The message was confusing due to that there are several different things named "ffmpeg", but it was not untrue.
    - lukaslalinsky 11y ago
      I always thought the message was intentionally confusing.
      - baldfat 11y ago
        It was untrue. It was a fork and they acted like ffmpeg was no longer being developed. To me this was a horrible way to fork something.
        acpmasquerade 11y ago
cookiecaper 11y ago
https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav gives an interesting perspective. Libav sounds like it's strict about good software practices and merciless in its exclusion and deletion of "bad" code. This may make a cleaner, more sustainable product over the long term, but it makes compatibility a nightmare now, which is probably why distro managers are increasingly interested in swapping libav back out. Perhaps if they had a more steady, formal release cycle it wouldn't be annoying and they'd have been able to maintain their position in the distros they got to carry them (I think almost all of them have reverted to ffmpeg as the default now). Since libav aggressively deletes old stuff and painstakingly reviews each patch (according to this article, no direct experience), they don't merge a lot of "new stuff" from ffmpeg. ffmpeg has maintained compatibility, making it really easy for downstream users and distro maintainers to keep going, whilst continuously adding new features and improvements, including aggressively merging those placed in libav (I guess as long as they aren't deletions or cleanups?). I feel like there's a lot to learn in this whole drama and that it hasn't been very deeply explored. libav team originally claimed that ffmpeg's leadership had gone dark/fallen off the map, but they sure came back quickly to express discontentment at the mutiny. libav team undoubtedly has talented people working on it (wasn't DarkShikari on the libav side of the schism?) and libav/ffmpeg share a lot of goals. You'd think they could come to some type of compromise less onerous than this entire saga has been. IMO it's a failure from all sides that this fork was even a thing. A phased, unified, slow, and well-managed release process like Python 2 -> Python 3 might have made all of this unnecessary.
- McGlockenshire 11y ago
  > You'd think they could come to some type of compromise less onerous than this entire saga has been. Given that the schism was based on politics and philosophy, I doubt that a compromise would have been possible. ffmpeg moves fast and sometimes gets sloppy, and was hard to version for distros. libav wanted slow and careful and clean and wanted to be distro friendly. Clearly libav tried to Do It Right(tm), but it looks like they ended up on the losing side of the fork. Forks only work when you can get the majority of developers to come along with you.
laurentoget 11y ago
Am i the only one who is amazed that the library which is supporting a huge share of all video playing on all linux machines appears to be pretty much written by one person?
- Sir_Cmpwn 11y ago
  https://github.com/FFmpeg/FFmpeg/graphs/contributors https://github.com/FFmpeg/FFmpeg/graphs/contributors 659 contributors. There are 14 people with over 1000 commits, 34 with over a hundred. 4 people with over 100K additions/deletions.
- pjc50 11y ago
  Free software relies disproportionally on a small number of people doing it for ideological reasons. It doesn't help that video codec work is particularly difficult and usually patent-encumbered. I'm still not sure whether ffmpeg is entirely non-patent infringing.
  - AndrewUnmuted 11y ago
    FFmpeg has some thoughts on this... Q: Does FFmpeg use patented algorithms? A: We do not know, we are not lawyers so we are not qualified to answer this. Also we have never read patents to implement any part of FFmpeg, so even if we were qualified we could not answer it as we do not know what is patented. Furthermore the sheer number of software patents makes it impossible to read them all so no one (lawyer or not) could answer such a question with a definite no, those who do lie. What we do know is that various standards FFmpeg supports contain vague hints that any conforming implementation might be subject to some patent rights in some jurisdictions Source: https://www.ffmpeg.org/legal.html https://www.ffmpeg.org/legal.html
    - pbhjpbhj 11y ago
      >number of software patents makes it impossible to read them all // IPC/ECLA (and probably whatever the USPTO use, USPC [IIRC]) allow for quite fine classification so it's not necessary to "read them all". The point is in there somewhere, and valid, but this phrasing seems just a little too flippant - to the point of deception. I don't doubt that there is a patent attorney/researcher/engineer in a company somewhere sufficiently on top of their game to say truthfully they don't infringe on any patents with their primary technology, patents valid in their jurisdiction, but it would certainly be a rare thing.
jtchang 11y ago
I don't think the single developer argument should be too much of a concern in an open source project. I saw Michael of ffmpeg had a lot of commits. In my experience with both closed and open sourced projects this is usually the case. There is one person that wrote the majority of the code. The great thing about open source is that even if they step away it's not like the code is going anywhere. To an end user of ffmpeg it would still continue to function. I personally had no idea ffmpeg was forked to libav until one day I tried to install it in Ubuntu and was like...wtf. Then I installed libav and went about my day.
- DanBC 11y ago
  His commit rate is high partly because he merges all libav commits too.
  - JoshTriplett 11y ago
    That's covered in the article; the projects both use git, so libav commits are merged with the original committers intact, not under someone else's name.
    - glandium 11y ago
      But the merge commits are still authored by Michael. Not having looked at the git repository, but if merges happen often, that can very much artificially inflate the number of commits attributed to him, except if the stats were gathered with --no-merges.
      - JoshTriplett 11y ago
        Are the commits from libav merged or cherry-picked/rebased? In any case, I would hope the stats were gathered with --no-merges; if not, that would indeed skew the stats.
        plorkyeran 11y ago
        There's a merge commit for each commit pulled from libav (and it's frequently not empty, as the codebases have diverged and so conflicts are common).
rsync 11y ago
Can ffmpeg play a DVD .iso ? I don't need menu support or parsing or anything ... I just wonder, can I point it at a DVD .iso and it will play video ?
- Bjartr 11y ago
  Well it can rip DVDs but ffmpeg doesn't display anything, the closest to playing anything ffmpeg can do is stream the media to something else that can then show it on screen. So, to answer the question you asked more directly: No, you can't point ffmpeg at anything and have it play video, because that's not what it does. Things that do that might use ffmpeg underneath depending on exactly what's being done.
  - gajjanag 11y ago
    It is true that ffmpeg can't do this directly. However, the ffmpeg project ships with a command line ffplay utility that is a very capable command line interface media player. This uses the libav* libraries of ffmpeg for its work. On a side note, ffplay has a really neat feature: while playing an audio file using ffplay, it displays a spectrogram by default.
    - keithpeter 11y ago
      Excellent. And clicking in the spectrogram window (launched ffmpeg from Gnome terminal so extra graphic window appears) jumps the playback to the appropriate % of the track.
gus_massa 11y ago
I don't like how they interpret the table with the numbers of commits. I tried this criteria, I divide the committers in three groups: A) Michael Niedermayer B) People with more commits in FFmpeg, i.e. Clément Bœsch, James Almer Carl, Eugen Hoyos, ... C) People with more commits in libav, i.e. Vittorio Giovara, Martin Storsjö, Anton Khirnov, ... (I supouse there are other commits from people outside the published table, but they are few.) Statistics: libav FFmpeg A) 46 1831 B) 37 1071 C) 1074 856 Tot: 1157 3758 An alternative interpretation is that if tomorrow Michael Niedermayer is hit by a bus, the other committers of FFmpeg still make almost the same numbers of commits than the committers of libav (even ignoring the ported commits). Complete table: Developer libav FFmpeg --------------------------------- Michael Niedermayer 46 1831 --------------------------------- Clément Bœsch 179 James Almer 155 Carl Eugen Hoyos 150 Andreas Cadhalpun 21 114 Lukasz Marek 98 Paul B Mahol 93 Ronald S. Bultje 85 wm4 16 83 Christophe Gisquet 66 Benoit Fouet 48 >>>Subtotal 37 1071 --------------------------------- Vittorio Giovara 294 294 Martin Storsjö 253 252 Anton Khirnov 206 197 Luca Barbato 131 113 Diego Biurrun 72 Rémi Denis-Courmont 32 Hendrik Leppkes 17 Himangi Saraogi 16 Gabriel Dume 16 Federico Tomassetti 14 Peter Meerwald 12 Janne Grunau 11 >>>Subtotal 1074 856 ------------------------------------ >>>>>>Total 1157 3758
- aleksi 11y ago
  My guess that Michael is (in git terms) committer, not patch author. Would be interesting to see table for authors.
  - RyJones 11y ago
    Good point. It's quite difficult to assign authorship automatically. Take a look at this not-yet-merged commit: https://git.allseenalliance.org/gerrit/#/c/4870/ https://git.allseenalliance.org/gerrit/#/c/4870/ who authored it? Todd. Who has signed off on editing it? Todd and me. How would you assign ownership? By LOC, Todd wrote essentially 100% of the patch, but since I edited it last, my name is last in the list of editors.
crystalgiver 11y ago
Yet another instance of "worse" is better: https://en.wikipedia.org/wiki/Worse_is_better https://en.wikipedia.org/wiki/Worse_is_better
- wsc981 11y ago
  I was thinking about that too, when I read the article. It seemed the libav guys are perfectionists, while the ffmpeg guys focus on getting things done. It made me wonder in my own professional work: should I also focus more on getting things done instead of trying to find the best solution? Will that approach give better results in the end? It's hard to tell if libav is more maintainable in the end, especially if no one will use it in the next few years, which might be the result of Debian backing down on libav. Still, the fact that ffmpeg has more features and its devs fix bugs and security issues more quickly seem to suggest that ffmpeg is more maintainable, even if the libav maintainer claims otherwise. --- In the end it's better to work on a (perhaps) less maintainable product that people use compared to a very maintainable product that no one uses.
  - cpeterso 11y ago
    Instead of building "perfect software", perfectionist can redirect their focus on finding the "perfect compromise" design. :)
    - netheril96 11y ago
      The perfectionist in me thinks in another way: time is an important resource and time taken should be considered a penalty from the perfection point. That is, if you spend too much time implementing a feature "perfectly", that is not perfect in the 4D spacetime continuum.
      - xenophonf 11y ago
        I like this way of thinking. I'm a perfectionist, too, but I'm also lazy. As a result I hate the idea of working hard on some beautiful piece of code that no one ends up using.
0x09 11y ago
> Libav on the other hand rather focuses on clean implementation and let's say better designed APIs. This is weird to hear as a consumer of these libraries. When people ask why I prefer one or the other for my own use cases, I tell them that FFmpeg has the better API and the better format support (specifically vastly more pixel formats/depths in its lossless codecs). But regarding API, at least the parts that concern me, FFmpeg is a bit fuller and requires less boilerplate. libav* have a large surface area, so even minor affordances like avformat_alloc_output_context2 and avcodec_find_best_pix_fmt_of_list are helpful. To be fair to Libav, due to being "downstream" FFmpeg has benefited greatly from their improvements, e.g. AVBuffer and the redone AVFrame management on top of it. They absolutely deserve credit for improving the API. But FFmpeg's API being effectively a superset of Libav, as a plain old user of the libraries it doesn't really make sense to target the latter. That's to say nothing about the politics or people involved in the projects, it's just a matter of practicality.
jacquesm 11y ago
Forking an important project like ffmpeg in a hostile manner is fraught with danger. More often than not these forks are not for technical reasons or philosophy, they're simply about ego. In a way it's like a me-too project but starting of the back of the contributers to the pre-fork one. This kind of behavior is lethal to open source projects, end users will end up fragmented across the two versions, package maintainers for the various distros have to make tough choices and everybody loses. Forking a project should be reserved for when a project becomes - by some objective criteria - abandoned and there is enough support for the project to continue. Then and only then should a project with a large amount of traction be forked. Forks are both the greatest thing in the open source world and the most annoying thing at the same time, they have the potential to rescue projects but more often than not they're used to kill projects. Really happy to see ffmpeg back, and I hope that the people that the majority of the contributors to libav switches to directly contribute to ffmpeg so that there will be an end to all the duplicated effort and wasted resources.
- chei0aiV 11y ago
  The libav fork of ffmpeg was primarily for technical reasons. Luckily those technical reasons have improved since the fork.
  - ank_the_elder 11y ago
    The fork happened for human reasons (management-related) rather than technical. See http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html and http://lwn.net/Articles/423703/ http://lwn.net/Articles/423703/
- kuschku 11y ago
  Well, no one will switch to ffmpeg – because the people who actually write most of the code you see in ffmpeg think the ffmpeg managers (admins? project leaders?) are assholes. The whole contributor base – everyone contributing to ffmpeg – tried to get the project leader out of the project, but he refused. So these people forked ffmpeg – or rather, they took all the repos (which they owned), took all the CI servers (which they owned) and would have also taken the name ffmpeg, but the project leader owned that name. It’s more of "one asshole vs. all the people writing the code he gives away" than anything else.
MicroBerto 11y ago
Would anyone be willing to provide a few commands for Ubuntu 14.04LTS that would install everything I need/want from ffmpeg and completely purge my system of libav? Thanks!

265 points by vezzy-fnord 11y ago

In almost every use case i have i have, libav has not been able to fulfill my needs and i have had to get rid of libav and install ffmpeg.

_delirium 11y ago
Do you have examples? I currently have libav on my Debian machines and ffmpeg on my Ubuntu machines, but haven't really noticed a difference for my needs. I'm not doing anything too complex, admittedly.
- simcop2387 11y ago
  One that I've encountered is that I had trouble setting up live streaming to youtube with libav. Something weird with the rtmp code, with ffmpeg it worked out of the box. Not sure if it matters that it was on a raspberry pi.
  - icelancer 11y ago
    This was my experience in using ffmpeg with an unrelated rtmp pipe as well. libav caused a ton of very strange and non-reproducible errors that were inconsistent. The switch back to ffmpeg cleaned up 90%+ of the problems.
- roghummal 11y ago
  Most of what I do with ffmpeg is change containers. Example: ffmpeg -i doom4_trailer.mkv -acodec copy -vcodec copy doom4_trailer.mp4 Pretty simple, right? libav: >[mp4 @ 0xa33800] Application provided invalid, non monotonically increasing dts to muxer in stream 0: -83 >= -83 >av_interleaved_write_frame(): Invalid argument (premature exit)
pvaldes 11y ago
Same with me, ffmpeg worked accurately and was extensively documented. Then a day there was no more here. I tried to understand the reasons and adopt avconv despite the ego wars, and those irritant message, and the cumbersome new syntax, and the lack of tutorials in internet... but finally the problem is that avconv just did not worked, and nobody really knew what to do with it. In the end I stopped using both programs. One was aparently unsafe and not installable without breaking things, and the other reinstall itself constantly, acts in a questionable way, and did not solve my problems. I guess that for Debian this was a false step that consumed time and resources but did more damage than good. Libav probably damaged also the image and dominant position of VLC. After several errors and troubles since them, its current luster is not the same as in the first years in my opinion.

wmantly 11y ago

About time, libav has never meet my needs.

wmantly 11y ago

About time, libav has never meet my needs.

andmarios 11y ago

As a Gentoo user, libav only gave me trouble. It was incompatible with many packages, whereas ffmpeg was with none I encountered. The switch to libav was horrific and I never managed to resolve all the issues it created with my system. For some months, updating my system was a herculean task due to libav causing constant —and largely unsolved— trouble. I was really happy to see Gentoo return to ffmpeg. Everything works smooth once again. I can't comment on code quality, project management, etc and frankly I don't care. If one library causes problems to every bit of my system, it should stay off until it is on par with the library it tries to replace —provided that both libraries use a free software compatible license.

tanderson92 11y ago
Can't you choose libav / ffmpeg as you see fit on Gentoo machines ?
- TheDong 11y ago
  Yes. Gentoo changed the default profile's use flags to include "libav", but adding USE="-libav" would get you back to the ffmpeg world. Gentoo has supported both for as long as its included libav at all.
- TheDong 11y ago
  Yes. Gentoo changed the default profile's use flags to include "libav", but adding USE="-libav" would get you back to the ffmpeg world. Gentoo has supported both for as long as its included libav at all.
- andmarios 11y ago
  Νear the end of 2014, libav became the default library. Until then it was up to the user to choose, so most of us were with ffmpeg due to our old use flags. Given the new status quo, my system refused to update since it would pull both libav due to the new profile and ffmpeg due to my use flags. As the Gentoo devs made this new choice, I thought I should embrace it, so I followed the steps to switch to libav. This created a nightmare of dependency issues that took me months to solve, especially given my limited time and that this happened on my main machine. I finally switched back to ffmpeg but it seemed to me that only when it —libav— was removed from Gentoo's default desktop profile my problems really stopped.

zimbatm 11y ago

Michael is just amazing. I once had a bug with ffmpeg which he helped me pin down on IRC and then produced a patch for it immediately. I was disappointed of how aggressive the libav guys where during the fork. They changed the content of ffmpeg.org (which they had legitimate access to) to claim that libav was now the new name of the project. Then they replaced the ffmpeg package in Debian with their own version. It's entirely possible to maintain both packages in Debian with the alternatives framework. This whole false dichotomy and calling ffmpeg the fork is not helpful in my opinion. So I'm glad that ffmpeg is getting it's package back. Forks are good and should stand on their own merit instead of doing politics like that.

camperman 11y ago
When I was told that ffmpeg was deprecated by libav, I immediately checked whether this was the truth. It wasn't. Bye bye libav - forever. Don't ever lie to your end users.
- plorkyeran 11y ago
  The libav version of the command line tool named "ffmpeg" was in fact deprecated and has since been removed entirely. The message was confusing due to that there are several different things named "ffmpeg", but it was not untrue.
  - lukaslalinsky 11y ago
    I always thought the message was intentionally confusing.
    - baldfat 11y ago
      It was untrue. It was a fork and they acted like ffmpeg was no longer being developed. To me this was a horrible way to fork something.
      - acpmasquerade 11y ago

cookiecaper 11y ago

https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav gives an interesting perspective. Libav sounds like it's strict about good software practices and merciless in its exclusion and deletion of "bad" code. This may make a cleaner, more sustainable product over the long term, but it makes compatibility a nightmare now, which is probably why distro managers are increasingly interested in swapping libav back out. Perhaps if they had a more steady, formal release cycle it wouldn't be annoying and they'd have been able to maintain their position in the distros they got to carry them (I think almost all of them have reverted to ffmpeg as the default now). Since libav aggressively deletes old stuff and painstakingly reviews each patch (according to this article, no direct experience), they don't merge a lot of "new stuff" from ffmpeg. ffmpeg has maintained compatibility, making it really easy for downstream users and distro maintainers to keep going, whilst continuously adding new features and improvements, including aggressively merging those placed in libav (I guess as long as they aren't deletions or cleanups?). I feel like there's a lot to learn in this whole drama and that it hasn't been very deeply explored. libav team originally claimed that ffmpeg's leadership had gone dark/fallen off the map, but they sure came back quickly to express discontentment at the mutiny. libav team undoubtedly has talented people working on it (wasn't DarkShikari on the libav side of the schism?) and libav/ffmpeg share a lot of goals. You'd think they could come to some type of compromise less onerous than this entire saga has been. IMO it's a failure from all sides that this fork was even a thing. A phased, unified, slow, and well-managed release process like Python 2 -> Python 3 might have made all of this unnecessary.

McGlockenshire 11y ago
> You'd think they could come to some type of compromise less onerous than this entire saga has been. Given that the schism was based on politics and philosophy, I doubt that a compromise would have been possible. ffmpeg moves fast and sometimes gets sloppy, and was hard to version for distros. libav wanted slow and careful and clean and wanted to be distro friendly. Clearly libav tried to Do It Right(tm), but it looks like they ended up on the losing side of the fork. Forks only work when you can get the majority of developers to come along with you.

laurentoget 11y ago

Am i the only one who is amazed that the library which is supporting a huge share of all video playing on all linux machines appears to be pretty much written by one person?

Sir_Cmpwn 11y ago
https://github.com/FFmpeg/FFmpeg/graphs/contributors https://github.com/FFmpeg/FFmpeg/graphs/contributors 659 contributors. There are 14 people with over 1000 commits, 34 with over a hundred. 4 people with over 100K additions/deletions.
pjc50 11y ago
Free software relies disproportionally on a small number of people doing it for ideological reasons. It doesn't help that video codec work is particularly difficult and usually patent-encumbered. I'm still not sure whether ffmpeg is entirely non-patent infringing.
- AndrewUnmuted 11y ago
  FFmpeg has some thoughts on this... Q: Does FFmpeg use patented algorithms? A: We do not know, we are not lawyers so we are not qualified to answer this. Also we have never read patents to implement any part of FFmpeg, so even if we were qualified we could not answer it as we do not know what is patented. Furthermore the sheer number of software patents makes it impossible to read them all so no one (lawyer or not) could answer such a question with a definite no, those who do lie. What we do know is that various standards FFmpeg supports contain vague hints that any conforming implementation might be subject to some patent rights in some jurisdictions Source: https://www.ffmpeg.org/legal.html https://www.ffmpeg.org/legal.html
  - pbhjpbhj 11y ago
    >number of software patents makes it impossible to read them all // IPC/ECLA (and probably whatever the USPTO use, USPC [IIRC]) allow for quite fine classification so it's not necessary to "read them all". The point is in there somewhere, and valid, but this phrasing seems just a little too flippant - to the point of deception. I don't doubt that there is a patent attorney/researcher/engineer in a company somewhere sufficiently on top of their game to say truthfully they don't infringe on any patents with their primary technology, patents valid in their jurisdiction, but it would certainly be a rare thing.

jtchang 11y ago

I don't think the single developer argument should be too much of a concern in an open source project. I saw Michael of ffmpeg had a lot of commits. In my experience with both closed and open sourced projects this is usually the case. There is one person that wrote the majority of the code. The great thing about open source is that even if they step away it's not like the code is going anywhere. To an end user of ffmpeg it would still continue to function. I personally had no idea ffmpeg was forked to libav until one day I tried to install it in Ubuntu and was like...wtf. Then I installed libav and went about my day.

DanBC 11y ago
His commit rate is high partly because he merges all libav commits too.
- JoshTriplett 11y ago
  That's covered in the article; the projects both use git, so libav commits are merged with the original committers intact, not under someone else's name.
  - glandium 11y ago
    But the merge commits are still authored by Michael. Not having looked at the git repository, but if merges happen often, that can very much artificially inflate the number of commits attributed to him, except if the stats were gathered with --no-merges.
    - JoshTriplett 11y ago
      Are the commits from libav merged or cherry-picked/rebased? In any case, I would hope the stats were gathered with --no-merges; if not, that would indeed skew the stats.
      - plorkyeran 11y ago
        There's a merge commit for each commit pulled from libav (and it's frequently not empty, as the codebases have diverged and so conflicts are common).

rsync 11y ago

Can ffmpeg play a DVD .iso ? I don't need menu support or parsing or anything ... I just wonder, can I point it at a DVD .iso and it will play video ?

Bjartr 11y ago
Well it can rip DVDs but ffmpeg doesn't display anything, the closest to playing anything ffmpeg can do is stream the media to something else that can then show it on screen. So, to answer the question you asked more directly: No, you can't point ffmpeg at anything and have it play video, because that's not what it does. Things that do that might use ffmpeg underneath depending on exactly what's being done.
- gajjanag 11y ago
  It is true that ffmpeg can't do this directly. However, the ffmpeg project ships with a command line ffplay utility that is a very capable command line interface media player. This uses the libav* libraries of ffmpeg for its work. On a side note, ffplay has a really neat feature: while playing an audio file using ffplay, it displays a spectrogram by default.
  - keithpeter 11y ago
    Excellent. And clicking in the spectrogram window (launched ffmpeg from Gnome terminal so extra graphic window appears) jumps the playback to the appropriate % of the track.

gus_massa 11y ago

I don't like how they interpret the table with the numbers of commits. I tried this criteria, I divide the committers in three groups: A) Michael Niedermayer B) People with more commits in FFmpeg, i.e. Clément Bœsch, James Almer Carl, Eugen Hoyos, ... C) People with more commits in libav, i.e. Vittorio Giovara, Martin Storsjö, Anton Khirnov, ... (I supouse there are other commits from people outside the published table, but they are few.) Statistics: libav FFmpeg A) 46 1831 B) 37 1071 C) 1074 856 Tot: 1157 3758 An alternative interpretation is that if tomorrow Michael Niedermayer is hit by a bus, the other committers of FFmpeg still make almost the same numbers of commits than the committers of libav (even ignoring the ported commits). Complete table: Developer libav FFmpeg --------------------------------- Michael Niedermayer 46 1831 --------------------------------- Clément Bœsch 179 James Almer 155 Carl Eugen Hoyos 150 Andreas Cadhalpun 21 114 Lukasz Marek 98 Paul B Mahol 93 Ronald S. Bultje 85 wm4 16 83 Christophe Gisquet 66 Benoit Fouet 48 >>>Subtotal 37 1071 --------------------------------- Vittorio Giovara 294 294 Martin Storsjö 253 252 Anton Khirnov 206 197 Luca Barbato 131 113 Diego Biurrun 72 Rémi Denis-Courmont 32 Hendrik Leppkes 17 Himangi Saraogi 16 Gabriel Dume 16 Federico Tomassetti 14 Peter Meerwald 12 Janne Grunau 11 >>>Subtotal 1074 856 ------------------------------------ >>>>>>Total 1157 3758

aleksi 11y ago
My guess that Michael is (in git terms) committer, not patch author. Would be interesting to see table for authors.
- RyJones 11y ago
  Good point. It's quite difficult to assign authorship automatically. Take a look at this not-yet-merged commit: https://git.allseenalliance.org/gerrit/#/c/4870/ https://git.allseenalliance.org/gerrit/#/c/4870/ who authored it? Todd. Who has signed off on editing it? Todd and me. How would you assign ownership? By LOC, Todd wrote essentially 100% of the patch, but since I edited it last, my name is last in the list of editors.

crystalgiver 11y ago

Yet another instance of "worse" is better: https://en.wikipedia.org/wiki/Worse_is_better https://en.wikipedia.org/wiki/Worse_is_better

wsc981 11y ago
I was thinking about that too, when I read the article. It seemed the libav guys are perfectionists, while the ffmpeg guys focus on getting things done. It made me wonder in my own professional work: should I also focus more on getting things done instead of trying to find the best solution? Will that approach give better results in the end? It's hard to tell if libav is more maintainable in the end, especially if no one will use it in the next few years, which might be the result of Debian backing down on libav. Still, the fact that ffmpeg has more features and its devs fix bugs and security issues more quickly seem to suggest that ffmpeg is more maintainable, even if the libav maintainer claims otherwise. --- In the end it's better to work on a (perhaps) less maintainable product that people use compared to a very maintainable product that no one uses.
- cpeterso 11y ago
  Instead of building "perfect software", perfectionist can redirect their focus on finding the "perfect compromise" design. :)
  - netheril96 11y ago
    The perfectionist in me thinks in another way: time is an important resource and time taken should be considered a penalty from the perfection point. That is, if you spend too much time implementing a feature "perfectly", that is not perfect in the 4D spacetime continuum.
    - xenophonf 11y ago
      I like this way of thinking. I'm a perfectionist, too, but I'm also lazy. As a result I hate the idea of working hard on some beautiful piece of code that no one ends up using.

0x09 11y ago

> Libav on the other hand rather focuses on clean implementation and let's say better designed APIs. This is weird to hear as a consumer of these libraries. When people ask why I prefer one or the other for my own use cases, I tell them that FFmpeg has the better API and the better format support (specifically vastly more pixel formats/depths in its lossless codecs). But regarding API, at least the parts that concern me, FFmpeg is a bit fuller and requires less boilerplate. libav* have a large surface area, so even minor affordances like avformat_alloc_output_context2 and avcodec_find_best_pix_fmt_of_list are helpful. To be fair to Libav, due to being "downstream" FFmpeg has benefited greatly from their improvements, e.g. AVBuffer and the redone AVFrame management on top of it. They absolutely deserve credit for improving the API. But FFmpeg's API being effectively a superset of Libav, as a plain old user of the libraries it doesn't really make sense to target the latter. That's to say nothing about the politics or people involved in the projects, it's just a matter of practicality.

jacquesm 11y ago

Forking an important project like ffmpeg in a hostile manner is fraught with danger. More often than not these forks are not for technical reasons or philosophy, they're simply about ego. In a way it's like a me-too project but starting of the back of the contributers to the pre-fork one. This kind of behavior is lethal to open source projects, end users will end up fragmented across the two versions, package maintainers for the various distros have to make tough choices and everybody loses. Forking a project should be reserved for when a project becomes - by some objective criteria - abandoned and there is enough support for the project to continue. Then and only then should a project with a large amount of traction be forked. Forks are both the greatest thing in the open source world and the most annoying thing at the same time, they have the potential to rescue projects but more often than not they're used to kill projects. Really happy to see ffmpeg back, and I hope that the people that the majority of the contributors to libav switches to directly contribute to ffmpeg so that there will be an end to all the duplicated effort and wasted resources.

chei0aiV 11y ago
The libav fork of ffmpeg was primarily for technical reasons. Luckily those technical reasons have improved since the fork.
- ank_the_elder 11y ago
  The fork happened for human reasons (management-related) rather than technical. See http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html and http://lwn.net/Articles/423703/ http://lwn.net/Articles/423703/
kuschku 11y ago
Well, no one will switch to ffmpeg – because the people who actually write most of the code you see in ffmpeg think the ffmpeg managers (admins? project leaders?) are assholes. The whole contributor base – everyone contributing to ffmpeg – tried to get the project leader out of the project, but he refused. So these people forked ffmpeg – or rather, they took all the repos (which they owned), took all the CI servers (which they owned) and would have also taken the name ffmpeg, but the project leader owned that name. It’s more of "one asshole vs. all the people writing the code he gives away" than anything else.

MicroBerto 11y ago

Would anyone be willing to provide a few commands for Ubuntu 14.04LTS that would install everything I need/want from ffmpeg and completely purge my system of libav? Thanks!