4 ms·

Complete 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 mu

Complete 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 ago
https://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.
astrange 7y ago
> Do you have proof of this claim, especially for "security issues"? ffmpeg was known for overly strict code reviews before the fork, but afterwards Michael N. (the lead dev) merged every single libav commit back in without review and called it weird names like "Qatar" he thought were funny. To be fair he was also schizophrenic and hallucinating. Good coder though. > Your phrasing makes it sound like the project lead was the instigator. He was quite difficult to work with, for instance you couldn't get him to delegate anything, and he wouldn't localize ffmpeg because it would take a few extra CPU cycles to look up strings in language tables. I haven't been able to look at the project in a while but he's probably better.

TheCycoONE 7y ago

https://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.

astrange 7y ago

> Do you have proof of this claim, especially for "security issues"? ffmpeg was known for overly strict code reviews before the fork, but afterwards Michael N. (the lead dev) merged every single libav commit back in without review and called it weird names like "Qatar" he thought were funny. To be fair he was also schizophrenic and hallucinating. Good coder though. > Your phrasing makes it sound like the project lead was the instigator. He was quite difficult to work with, for instance you couldn't get him to delegate anything, and he wouldn't localize ffmpeg because it would take a few extra CPU cycles to look up strings in language tables. I haven't been able to look at the project in a while but he's probably better.