Hacker News new | comments | show | ask | jobs | submit login

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]

1. http://www.i-programmer.info/news/98-languages/8269-python-2...

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.

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

Sadly, when installing it on my computer the other day, the only python that got installed automatically was Python2.

It's still nice to have Python3 be the default as a Python3 developer.

Python 3 has been the default on Arch for 3 or 4 years now. If only Python 2 was installed, it's because you installed a package that required python2 and didn't install python explicitly.

$ pacaur -Qi python Name : python Version : 3.4.3-2

It's definitely been slow for Python 3 but in my experience most new projects are using it now. The mainstream distributions are planning to make Py3 the default Python in their upcoming releases. Almost all important libraries in Py2 have been ported or replaced by now. There are still some curmudgeons that haven't gotten the memo on Py3, but they'll become almost non-existent over the next year or two.

Python 3 adoption was a little slower than may have been ideal, but I personally think it was a very successful way to implement breaking changes, especially when it could've been a libav/ffmpeg-style mess.

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

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

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.

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.

Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact