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.
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.
> It's entirely possible to maintain both packages in Debian with the alternatives framework.
The Debian security team vetoed this option, which is why the recent discussion was choosing between, 1) bring back ffmpeg and remove libav, or 2) keep libav and do not bring back ffmpeg (option 1 was chosen). They don't want to support security patches for both, and for all combinations of software that might use either one.
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
As you can see many of the other major contributors to ffmpeg are also contributors to libav.
This is explained that ffmpeg merges back a lot of libav but not so much in the other direction.
In other words, if this is true and all major contributors except for Michael are in fact libav developers then ffmpeg might have a hard time when Michael leaves.
But since Michael alone seems to "outdevelop" all others, ffmpeg comes ahead in terms of features and supported codecs, so people prefer ffmpeg. Since i don't know the ffmpeg APIs or the code quality, i don't know if it is true that ffmpeg has the worse design and development process. If it is true and Michael leaves it sounds like a lot work to take over. On the other hand... i understand that libav was already a fork of ffmpeg.. So some people did take over the code in the past.
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.
That problem existed in both directions. Packages written to ffmpeg would have trouble building with libav, and packages written to libav would have trouble building with ffmpeg. For an example of the latter, gstreamer adapted its ffmpeg plugin to become a libav plugin, and that plugin now doesn't always build against ffmpeg without some effort.
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.
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.
What about Hudson/Jenkins and OpenOffice/LibreOffice? And egcs?
I think criticizing forking is misguided; the fork is a consequence of the problem, not the cause, and it can often be the best resolution of a bad situation.
Consider what would have happened if it was impossible to fork ffmpeg: the developers who created libav would still have a problem with how ffmpeg was developed, and they could very well simply leave it. That would mean a loss to ffmpeg itself (which used the libav patches), a loss of the libav developers, and for what?
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.
> 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.
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.
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.
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.
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.
> A phased, unified, slow, and well-managed release process like Python 2 -> Python 3 might have made all of this unnecessary.
This is at total nit, but I really doubt emulating the Python 2 -> Python 3 release process would go high on anybody's list of successful project evolutions. Given that Python 3 was officially released in 2008, it's worth keeping in mind that as recently as 2014 most new projects were still being created in Python 2.x[1]
> 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.
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?
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.
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?
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.
libav has less features and is less secure. If they can't keep up with fixing security bugs, I can't help but wonder on how they fare on less important bugs, probably not that good either.
Given how there appear to be no problems adding new features to ffmpeg, any technical debt the project has incurred seems to be within manageable range.
It doesn't look at all, as if libav is better, by any reasonable metric.
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.
[+] [-] zimbatm|10 years ago|reply
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|10 years ago|reply
[+] [-] _delirium|10 years ago|reply
The Debian security team vetoed this option, which is why the recent discussion was choosing between, 1) bring back ffmpeg and remove libav, or 2) keep libav and do not bring back ffmpeg (option 1 was chosen). They don't want to support security patches for both, and for all combinations of software that might use either one.
[+] [-] Daviey|10 years ago|reply
It isn't quite as simple as this when we are talking about libraries... Which one is used by other packages to build against?
Whichever is used, has to become the runtime dependency.
[+] [-] perlgeek|10 years ago|reply
It is, but it is also a big maintenance burden, in particular for the security team.
[+] [-] gus_massa|10 years ago|reply
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:
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:
[+] [-] buster|10 years ago|reply
But since Michael alone seems to "outdevelop" all others, ffmpeg comes ahead in terms of features and supported codecs, so people prefer ffmpeg. Since i don't know the ffmpeg APIs or the code quality, i don't know if it is true that ffmpeg has the worse design and development process. If it is true and Michael leaves it sounds like a lot work to take over. On the other hand... i understand that libav was already a fork of ffmpeg.. So some people did take over the code in the past.
Just restating what the article says.
[+] [-] aleksi|10 years ago|reply
[+] [-] andmarios|10 years ago|reply
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.
[+] [-] JoshTriplett|10 years ago|reply
[+] [-] tanderson92|10 years ago|reply
[+] [-] jacquesm|10 years ago|reply
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.
[+] [-] icebraining|10 years ago|reply
What about Hudson/Jenkins and OpenOffice/LibreOffice? And egcs?
I think criticizing forking is misguided; the fork is a consequence of the problem, not the cause, and it can often be the best resolution of a bad situation.
Consider what would have happened if it was impossible to fork ffmpeg: the developers who created libav would still have a problem with how ffmpeg was developed, and they could very well simply leave it. That would mean a loss to ffmpeg itself (which used the libav patches), a loss of the libav developers, and for what?
[+] [-] chei0aiV|10 years ago|reply
[+] [-] kuschku|10 years ago|reply
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.
[+] [-] 0x09|10 years ago|reply
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.
[+] [-] callesgg|10 years ago|reply
[+] [-] _delirium|10 years ago|reply
[+] [-] pvaldes|10 years ago|reply
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.
[+] [-] jtchang|10 years ago|reply
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|10 years ago|reply
[+] [-] cookiecaper|10 years ago|reply
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.
[+] [-] venantius|10 years ago|reply
This is at total nit, but I really doubt emulating the Python 2 -> Python 3 release process would go high on anybody's list of successful project evolutions. Given that Python 3 was officially released in 2008, it's worth keeping in mind that as recently as 2014 most new projects were still being created in Python 2.x[1]
1. http://www.i-programmer.info/news/98-languages/8269-python-2...
[+] [-] McGlockenshire|10 years ago|reply
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|10 years ago|reply
[+] [-] Sir_Cmpwn|10 years ago|reply
659 contributors. There are 14 people with over 1000 commits, 34 with over a hundred. 4 people with over 100K additions/deletions.
[+] [-] pjc50|10 years ago|reply
[+] [-] MicroBerto|10 years ago|reply
Thanks!
[+] [-] wmantly|10 years ago|reply
[+] [-] crystalgiver|10 years ago|reply
[+] [-] wsc981|10 years ago|reply
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.
[+] [-] DasIch|10 years ago|reply
Given how there appear to be no problems adding new features to ffmpeg, any technical debt the project has incurred seems to be within manageable range.
It doesn't look at all, as if libav is better, by any reasonable metric.
[+] [-] zurn|10 years ago|reply
[+] [-] wmantly|10 years ago|reply
[deleted]
[+] [-] rsync|10 years ago|reply
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|10 years ago|reply