4 ms·

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 so

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.
- dtech 11y ago
  Also, according to a ffmpeg contributor [1] (who joined after the schism) they just refused to merge anything by ffmpeg, often doing identical functionality from scratch (because users wanted it after seeing it in ffmpeg). Meanwhile ffmpeg merged basically everything from libav. Furthermore ffmpeg made an effort to provide compatibility, even for stuff where libav intentionally broke compatibility. So basically ffmpeg benefitted from all the work put into libav but not the other way around. Seems to me that they brought this upon themselves. [1]: http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
- cookiecaper 11y ago
  Obviously the fork was politically driven. That doesn't mean that compromise was impossible. If both sides had more respect for the concern of the other, there's no reason an aggressive ffmpeg hygiene project couldn't have been officially sanctioned. They could've kept the mainstream API and developed a plan to release the cleaned, backwards-incompatible next-gen API in a way that would've actually seen adoption. libav is doing good cleanup work, but the fact that there is a political barrier the participants haven't been able to amicably dissolve is going to stop us from benefiting from it, and that's a real shame.
  - plorkyeran 11y ago
    All of Libav's API changes and changes to the command-line tool (other than renaming them) have been merged by FFmpeg, usually very promptly, and by now a lot of the older pre-Libav APIs have been dropped entirely. The fork has not in any way prevented anyone from benefiting from Libav's work. While the two projects have chosen somewhat different approaches to developing the software, these differences were not what lead to the fork, and neither project particularly resembles pre-fork FFmpeg.
venantius 11y ago
> 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] 1. http://www.i-programmer.info/news/98-languages/8269-python-2-versus-python-3-revisited.html http://www.i-programmer.info/news/98-languages/8269-python-2...
- deckiedan 11y ago
  I'm not sure there is a good way to do a breaking change to a programming language in a good way. That said, given that python 2.7 is being continued to be maintained - but not with new features - for such a long time, and letting python 3 evolve quite quickly until it's now actually beginning (finally, around 3.5ish) to have features which are really appealing to many users (the async stuff, type hinting, etc), I don't think they've done too badly. They could have made it quicker to happen, but since python2.7 is still a very good language, and works stably on practially every OS you could want, why try to force a change until people are ready? People bitch about it [the changeover] a lot - not because it's terrible, but because it's lasting such a long time. AFAIK, NO mainstream OS is shipping python3 as the main python, or even as a default installed python, yet. Most big libs work in python3 now. I reckon in 5 years time python3 should be the default install, with 2.7 as the legacy extra package for people who need it. One way that could have been helpful (and may even be possible?????) would be a -2k flag for python3 which runs in python2.7 compatibility mode, or something. I dunno.
  - Qwertious 11y ago
    >AFAIK, NO mainstream OS is shipping python3 as the main python, or even as a default installed python, yet. IIRC, Arch Linux does. Bleeding Edge. From the Arch Wiki: >To install the latest version of Python 3, install the `python` package from the official repositories.
    - 11y ago

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.

dtech 11y ago
Also, according to a ffmpeg contributor [1] (who joined after the schism) they just refused to merge anything by ffmpeg, often doing identical functionality from scratch (because users wanted it after seeing it in ffmpeg). Meanwhile ffmpeg merged basically everything from libav. Furthermore ffmpeg made an effort to provide compatibility, even for stuff where libav intentionally broke compatibility. So basically ffmpeg benefitted from all the work put into libav but not the other way around. Seems to me that they brought this upon themselves. [1]: http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
cookiecaper 11y ago
Obviously the fork was politically driven. That doesn't mean that compromise was impossible. If both sides had more respect for the concern of the other, there's no reason an aggressive ffmpeg hygiene project couldn't have been officially sanctioned. They could've kept the mainstream API and developed a plan to release the cleaned, backwards-incompatible next-gen API in a way that would've actually seen adoption. libav is doing good cleanup work, but the fact that there is a political barrier the participants haven't been able to amicably dissolve is going to stop us from benefiting from it, and that's a real shame.
- plorkyeran 11y ago
  All of Libav's API changes and changes to the command-line tool (other than renaming them) have been merged by FFmpeg, usually very promptly, and by now a lot of the older pre-Libav APIs have been dropped entirely. The fork has not in any way prevented anyone from benefiting from Libav's work. While the two projects have chosen somewhat different approaches to developing the software, these differences were not what lead to the fork, and neither project particularly resembles pre-fork FFmpeg.

venantius 11y ago

> 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] 1. http://www.i-programmer.info/news/98-languages/8269-python-2-versus-python-3-revisited.html http://www.i-programmer.info/news/98-languages/8269-python-2...

deckiedan 11y ago
I'm not sure there is a good way to do a breaking change to a programming language in a good way. That said, given that python 2.7 is being continued to be maintained - but not with new features - for such a long time, and letting python 3 evolve quite quickly until it's now actually beginning (finally, around 3.5ish) to have features which are really appealing to many users (the async stuff, type hinting, etc), I don't think they've done too badly. They could have made it quicker to happen, but since python2.7 is still a very good language, and works stably on practially every OS you could want, why try to force a change until people are ready? People bitch about it [the changeover] a lot - not because it's terrible, but because it's lasting such a long time. AFAIK, NO mainstream OS is shipping python3 as the main python, or even as a default installed python, yet. Most big libs work in python3 now. I reckon in 5 years time python3 should be the default install, with 2.7 as the legacy extra package for people who need it. One way that could have been helpful (and may even be possible?????) would be a -2k flag for python3 which runs in python2.7 compatibility mode, or something. I dunno.
- Qwertious 11y ago
  >AFAIK, NO mainstream OS is shipping python3 as the main python, or even as a default installed python, yet. IIRC, Arch Linux does. Bleeding Edge. From the Arch Wiki: >To install the latest version of Python 3, install the `python` package from the official repositories.
  - 11y ago