4 ms·
> This is ridiculous All you’re saying is repeating what I stated — libav removed unclean code and focused on cleaning it up, even if that meant losing a lot o
by kuschku 7y ago
> This is ridiculous
All you’re saying is repeating what I stated — libav removed unclean code and focused on cleaning it up, even if that meant losing a lot of functionality.
At the same time, ffmpeg merged pretty much everything, even if that lead to worse code, or security issues.
Yes, libav was slower in patching, but the goals with which it started were good in nature.
> There was longstanding animosity between the project lead and other developers, due to a variety of reasons, mainly his dictatorial leadership style.
That’s nothing different from what I said, I just tried to phrase it more nicely.
> It wasn't cleaner, just less. It became more and more "less" when ffmpeg gained new (well-designed) features, and libav refused to merge them just because they were not designed by libav.
More isn’t better. FFmpeg is one of the buggiest and most broken collections of code on this planet. Clean code, maintainability, and so on are actually important.
Look at libressl — they ripped out 90% of the functionality of openssl, cleaned up the API surfaces, etc. And yes, right now they’re still slower to patch some kinds of bugs than openssl, but once they patch them, they actually stay fixed, while each openssl patch opens a dozen new bugs.
- liability 7y agoLibav broke my scripts that had been working for years and had the audacity to claim ffmpeg was deprecated. I'm never glad when a FOSS project crashes and burns, but this is the exception that 'proves' the rule. Good riddance!
- Hello71 7y agowhat security issues were prevented by libav's wholesale removal of working code? why did libav implement new ffmpeg features in gratuitously incompatible ways? why did libav print the hilariously defamatory "FFMPEG IS DEPRECATED" message?
- kuschku 7y ago> what security issues were prevented by libav's wholesale removal of working code? ffmpeg has a lot of areas where the cold is old, barely maintained, and has many issues. Have you tried running ffmpeg through a static analysis tool? the resulting warning list will be so large, it wouldn’t fit on a floppy. libav’s first action was removing such unclean code, which was a good thing, the project started with a good motivation, similar to libreSSL — they also ripped out 90% of working code to clean the codebase up. > why did libav implement new ffmpeg features in gratuitously incompatible ways? > why did libav print the hilariously defamatory "FFMPEG IS DEPRECATED" message? Humans are humans, and tribalism is everywhere. After such a fight, usually the groups both declare the other side wrong, and do everything in their might to make their position more popular. That’s not saying it’s justified, and I won’t make a judgement on these actions, nor am I going to declare which side was good or bad, just that libav started with some good ideals, before this happened.
- thenewnewguy 7y agoComplete outsider (literally learning about this fight via this post), but I have to admit you seem somwhat biased: > At the same time, ffmpeg merged pretty much everything, even if that lead to worse code, or security issues. Do you have proof of this claim, especially for "security issues"? > That’s nothing different from what I said, I just tried to phrase it more nicely. Your phrasing makes it sound like the project lead was the instigator. > FFmpeg is one of the buggiest and most broken collections of code on this planet. Again, do you have proof of this? I'll admit my experience with ffmpeg is minor, but it seemed like a fairly normal software project when I worked with it rather than a buggy mess.
- TheCycoONE 7y agohttps://security.googleblog.com/2014/01/ffmpeg-and-thousand-fixes.html https://security.googleblog.com/2014/01/ffmpeg-and-thousand-... https://alioth-lists.debian.net/pipermail/pkg-multimedia-maintainers/2015-May/044532.html https://alioth-lists.debian.net/pipermail/pkg-multimedia-mai... I believe every major distro that jumped to libav has switched back. Some appearance of bias may be just a statement of fact. ffmpeg frequently merged changes from libav, but not vice versa. The newly commissioned (around the time of the fork) library libswresample for example was never brought over to libav, despite being far more ergonomic than libavresample.
- kuschku 7y ago> Your phrasing makes it sound like the project lead was the instigator. Fixed that > Again, do you have proof of this? Most media code is already a huge bunch of a buggy mess, and more obscure codecs are usually the worst examples of this. Which is why gstreamer splits the codecs into groups based on how well they are maintained and how clean the code is. If you read the CVE lists for ffmpeg, you’ll notice that a lot of them are in not so well maintained codecs or functionality (often in parts libav threw out, which annoyed the people who needed this), or in parts where ffmpeg reinvents the world. It’s a common issue in many projects, and especially in the media world with obscure codecs which often only a handful of people — or only one person — even understand anymore it’s a major problem, and just like with OpenSSL/LibreSSL, it’s a good reason to rip this code out.
- 7y ago