4 ms·

> 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 philosoph

> 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.

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.