4 ms·

So what is the difference? This comment looks to be adhomenum remarks on forks. If it’s clear and I’m just missing it, sorry i have a temp of 102.3 so I’m a li

by Jaepa 7y ago

So what is the difference? This comment looks to be adhomenum remarks on forks. If it’s clear and I’m just missing it, sorry i have a temp of 102.3 so I’m a little hazy.

anoncareer0212 7y ago
TL;DR: Use ffmpeg Man, if these reads like ad hominem, I wish you could read the whole story. The linked comment is admirably restrained to the point it prefers being confusing over explaining what happened (fwiw I have no dog in the fight, was privy to the goings-on because my project depended on ffmpeg)
- Jaepa 7y ago
  Alright. Got it thank you.
kuschku 7y ago
Most of the core contributors had a fight with the project lead, so many of them left the project and forked into libav. So the community and the projects both split, and both fought about being the real one. And at first, ffmpeg focused only on features, regardless of code quality, while libav focused on clean code, even if that meant compromising on features. Obviously, people who aligned with the project lead, and people wondering why stuff suddenly didn’t work anymore, were fed up with libav. Even though it was a situation where libavs codebase was, compared to ffmpeg, much cleaner, similar to openssl vs libressl, but sacrificed a huge amount of functionality for that goal. EDIT: Rephrasing for accuracy
- Hello71 7y ago
  I have no bone in this fight, but this is an egregiously terrible and biased summary. I will pick some of the most ridiculous points here to rebut, but a better summary could be found in literally any of the search results for "ffmpeg libav". > The project lead had a fight with all the other core contributors There was longstanding animosity between the project lead and other developers, due to a variety of reasons, mainly his dictatorial leadership style. > everyone but the lead left the project and forked into libav A small set of contributors with technical control over certain infrastructure removed the lead's access. > So the community and the projects both split, and both fought about being the real one. This contradicts your previous claim that "everyone but the lead left the project". > And at first, ffmpeg focused only on features, regardless of security, while libav focused on security and clean code, even if that meant compromising on features. This is ridiculous. libav did remove a large amount of code that was working, some of which may have been insecure or not designed well, but a lot of which was actually necessary for people's workflows and not "dead code" as they claimed. Moreover, ffmpeg had a significantly better security profile than libav due to actually patching bugs rather than waiting to do it right (which ffmpeg developers will argue was basically "doing it differently than ffmpeg"). > Even though it was a situation where libavs codebase was, compared to ffmpeg, much cleaner, similar to openssl vs libressl. 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.
  - 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 ago
      Libav 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 ago
      what 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.
- jorvi 7y ago
  If you check this link[0] you can see most of your statement about FFmpeg merging everything and Libav being all about clean code is just completely false. Apparently lots of hardcoding and weird NIH on the Libav side, and a biased Ubuntu package maintainer to boot. [0] http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
  - anoncareer0212 7y ago
    I can vouch for this being impartial and generous at the time, with context – without context it reads a little too much like hectoring
  - devy 7y ago
    That linked article is from 2012, still relevant? In other words, has some of the things mentioned changed?
    - plorkyeran 7y ago
      Libav mostly died over the last ~2 years, with the developers either returning to ffmpeg or moving on entirely.
    - cwyers 7y ago
      The big change since then is that Debian switched back to ffmpeg: https://lwn.net/Articles/650816/ https://lwn.net/Articles/650816/

by Jaepa 7y ago

So what is the difference? This comment looks to be adhomenum remarks on forks. If it’s clear and I’m just missing it, sorry i have a temp of 102.3 so I’m a little hazy.

anoncareer0212 7y ago

TL;DR: Use ffmpeg Man, if these reads like ad hominem, I wish you could read the whole story. The linked comment is admirably restrained to the point it prefers being confusing over explaining what happened (fwiw I have no dog in the fight, was privy to the goings-on because my project depended on ffmpeg)

Jaepa 7y ago
Alright. Got it thank you.

kuschku 7y ago

Most of the core contributors had a fight with the project lead, so many of them left the project and forked into libav. So the community and the projects both split, and both fought about being the real one. And at first, ffmpeg focused only on features, regardless of code quality, while libav focused on clean code, even if that meant compromising on features. Obviously, people who aligned with the project lead, and people wondering why stuff suddenly didn’t work anymore, were fed up with libav. Even though it was a situation where libavs codebase was, compared to ffmpeg, much cleaner, similar to openssl vs libressl, but sacrificed a huge amount of functionality for that goal. EDIT: Rephrasing for accuracy

Hello71 7y ago
I have no bone in this fight, but this is an egregiously terrible and biased summary. I will pick some of the most ridiculous points here to rebut, but a better summary could be found in literally any of the search results for "ffmpeg libav". > The project lead had a fight with all the other core contributors There was longstanding animosity between the project lead and other developers, due to a variety of reasons, mainly his dictatorial leadership style. > everyone but the lead left the project and forked into libav A small set of contributors with technical control over certain infrastructure removed the lead's access. > So the community and the projects both split, and both fought about being the real one. This contradicts your previous claim that "everyone but the lead left the project". > And at first, ffmpeg focused only on features, regardless of security, while libav focused on security and clean code, even if that meant compromising on features. This is ridiculous. libav did remove a large amount of code that was working, some of which may have been insecure or not designed well, but a lot of which was actually necessary for people's workflows and not "dead code" as they claimed. Moreover, ffmpeg had a significantly better security profile than libav due to actually patching bugs rather than waiting to do it right (which ffmpeg developers will argue was basically "doing it differently than ffmpeg"). > Even though it was a situation where libavs codebase was, compared to ffmpeg, much cleaner, similar to openssl vs libressl. 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.
- 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 ago
    Libav 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 ago
    what 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.
jorvi 7y ago
If you check this link[0] you can see most of your statement about FFmpeg merging everything and Libav being all about clean code is just completely false. Apparently lots of hardcoding and weird NIH on the Libav side, and a biased Ubuntu package maintainer to boot. [0] http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
- anoncareer0212 7y ago
  I can vouch for this being impartial and generous at the time, with context – without context it reads a little too much like hectoring
- devy 7y ago
  That linked article is from 2012, still relevant? In other words, has some of the things mentioned changed?
  - plorkyeran 7y ago
    Libav mostly died over the last ~2 years, with the developers either returning to ffmpeg or moving on entirely.
  - cwyers 7y ago
    The big change since then is that Debian switched back to ffmpeg: https://lwn.net/Articles/650816/ https://lwn.net/Articles/650816/