7 ms·

I don't know the extent of the drama, but I have used FFMpeg a decent amount and it's been a lifesaver. I know that OSS leaders are extremely under appreciated,

I don't know the extent of the drama, but I have used FFMpeg a decent amount and it's been a lifesaver. I know that OSS leaders are extremely under appreciated, and I'd like to thank Michael for all of his efforts doing so.

jbk 11y ago
> I don't know the extent of the drama As a heavy user of FFmpeg/libav, for VLC (I'm the VideoLAN president), the drama has been huge, and more aggressive than most forks we've seen in the open source community. Most of the information you find online is biased, wrong or down-right lying, including the usual blogposts that are quoted from one side or the other one. (like the pkh.me pasted or the Debian wiki one) Whose fault is it? Well, it's a bit complex to answer, and there has been very dick moves from both sides. Especially since the beginning of the story started in private and was not reported publicly. Who is doing more work between the forks? That's also very hard to answer, because most of the libavcodec and libavformat work has been done in libav, but most of the libavfilter, ffmpeg and tools work has been done in FFmpeg. What you should know is that the current codebase of FFmpeg is messier compared to libav, but has quite a few more features, notably filters and more formats supported. Choosing one or the other gives you different set of features, but mostly different set of bugs and level of support of codecs. It's a big mess...
- flihp 11y ago
  Really unfortunate because the software is so useful.
  - jacquesm 11y ago
    And that's probably one of the reasons for this whole debacle. A project without adoption would not be worth fighting over.
- ux 11y ago
  I'd be surprised if you had actually read the blog post I wrote (pkh.me) :) > most of the libavcodec and libavformat work has been done in libav Well, I believe this is a bit more complex. While it might be true for API changes and cleanups, FFmpeg has dozens of additionnal codecs and formats, as well as way more assembly/optimization code. > What you should know is that the current codebase of FFmpeg is a huge mess compared to libav Honestly, this is pure FUD and it's very surprising to read that from you. You seem to have no idea about the cleanups of FFmpeg because we do not advertise them (they are not relevant for the users). What is so much a huge mess? This is very insulting for the work done by FFmpeg developers these last years. Hey, even libmpcodecs (the MPlayer filter wrapper) is no more. A lot of work was also done on the documentation. Seriously, please stop doing FUD like this. > Choosing one or the other gives you different set of features Not exactly true.
  - jbk 11y ago
    > I'd be surprised if you had actually read the blog post I wrote (pkh.me) :) I did, and many times. And I already said so. > Well, I believe this is a bit more complex. Unfortunately, it's more complex, yes, but it's not that much. Elenril, Koda and Martin are the one spending the more times and commits on libavcodec and libavformat. > Honestly, this is pure FUD and it's very surprising to read that from you. It's not. Unfortunately. Who has multiple implementations of the same codecs (2 prores decoders, at least 2 prores encoders) or libraries (2 resampling libraries) ? Who is spending hours removing the famous MPEG12EncContext from everywhere? And I don't even speak about the refusal to removing the non-working xvmc support for MPEG2. And sorry, but you are one side, that joined after the fork. Attacking me is not really objective. > Not exactly true. Of course it is. Every time I do package VLC I need to choose one fork over the other and every time that means a different bug. This is documented over and over on our wiki and our bugtracker... EDIT: I'm sorry you (and other) took that as an attack on FFmpeg. We use FFmpeg over libav in the current VLC windows and Mac version.
    - otis_inf 11y ago
      > Attacking me is not really objective. In the decades I'm developing software, I've learned that there is no developer out there liking somebody else's code. There's always something. You can think you're objective and unbiased, but you're not, no-one is. FFMpeg's code might be a mess due to a large chunk of legacy / backwards compatibility code, but very likely the other side's code base is a mess in other people's eyes.
- emcrazyone 11y ago
  " FFmpeg is a huge mess compared to libav" I assume this is an unbiased opinion as much as it can be but could you elaborate on what about FFmpeg is a "mess." I've used both these libraries in building MythTV from strictly a user perspective. Both code bases are open source. I'm wondering if there is so much turmoil here, why doesn't someone (like VLC) take the best features from both projects and create their own library? I never understood the OSS communities. It just seems simple to me. If you don't like it, fork it and do your own. <shrug>
  - jbk 11y ago
    > I assume this is an unbiased opinion as much as it can be but could you elaborate on what about FFmpeg is a "mess." Examples: 2 prores decoders, 2 prores encoders (or 3), 2 different resampling libraries, libstagefright integration that does not work, more global context structures compared to libav, etc... They also refused to remove some very outdated (non-working) code like xvmc. > why doesn't someone (like VLC) take the best features from both projects and create their own library? Because it's a lot of work. An enormous work.
    - zvrba 11y ago
      Having multiple implementations of a feature does not make it a "mess" unless they step on each other's toes.
    - makomk 11y ago
      If I remember correctly, a big part of the reason that ffmpeg ended up with two resampling libraries is that after they'd created theirs, libav wrote their own with a different, totally incompatible API and ffmpeg wanted to support applications that were written for the libav API.
      - loup-vaillant 11y ago
        "There is a reason for everything" Scott Meyers, talking of the various… quirks of C++. https://www.youtube.com/watch?v=48kP_Ssg2eY https://www.youtube.com/watch?v=48kP_Ssg2eY
- scrollaway 11y ago
  The whole situation is really representative of the whole philosophy of doing aggressive cleanups/rewrites. Maybe it'll improve things on the very long term, but you will have a really, really long period where your product is completely unusable, and will drive a lot of pure frustration. I hope some big entity ends up throwing money at the situation, it seems fixable, just a lack of manpower to fix it. I mean, Google relies on it a whole lot for one.
- shmerl 11y ago
  With this change, is merging of the projects now a possibility?
  - jbk 11y ago
    Let's hope so?
  - aidenn0 11y ago
    Like jbk, I'd like to hope it will happen, but the combination of significant tribalism, plus the very different development philosophies may prevent this. For the merging to happen, there would have to be both some agreement on the technical direction of the two projects, as well as some sort of social resolution, which would likely involve some maintainers of one fork or the other leaving. Regardless, from my point of view, it seems unsustainable to keep on merging from libav to ffmpeg at the pace that Michael has been doing, so the projects will end up diverging enough at one point that momentum ends up behind one or the other.
- bjourne 11y ago
  Is the info about the attempted coup d'état wrong then? Because that's completely nasty. If you don't like the project leader, make a real fork and hope there is enough of you who will jump ship. Abusing the fact that you control the infrastructure to try and lock out the old leader is bad.
  - jbk 11y ago
    > Is the info about the attempted coup d'état wrong then? It's partially untrue, yes. There was an actual vote from all the active developers to remove Michael from leadership, and that included the infrastructure developers. But yes, the fork was very badly done.
    - gillianseed 11y ago
      >It's partially untrue, yes. There was an actual vote from all the active developers to remove Michael from leadership, and that included the infrastructure developers. Then why did so many remain with the ffmpeg project instead of going with libav ?
      - Flowdalic 11y ago
        It appears the opposite is true. ffmpeg is more or less a one man show. See http://thread.gmane.org/gmane.linux.debian.alioth.multimedia-maintainers/37620 http://thread.gmane.org/gmane.linux.debian.alioth.multimedia... and https://lwn.net/Articles/650816/ https://lwn.net/Articles/650816/ "I think the statistics indicate that the situation is much worse than I expected. Please keep in mind that because of the daily merges, all commits that are made in Libav also appear in FFmpeg, but not the other way round. With a finger-in-the-wind estimate of subtracting the numbers in the Libav table from the FFmpeg table, the distance between Michael and the other FFmpeg developers because even more extreme."
    - Qwertious 11y ago
      What were the results of the vote? Are you saying Michael was voted out?

jbk 11y ago

> I don't know the extent of the drama As a heavy user of FFmpeg/libav, for VLC (I'm the VideoLAN president), the drama has been huge, and more aggressive than most forks we've seen in the open source community. Most of the information you find online is biased, wrong or down-right lying, including the usual blogposts that are quoted from one side or the other one. (like the pkh.me pasted or the Debian wiki one) Whose fault is it? Well, it's a bit complex to answer, and there has been very dick moves from both sides. Especially since the beginning of the story started in private and was not reported publicly. Who is doing more work between the forks? That's also very hard to answer, because most of the libavcodec and libavformat work has been done in libav, but most of the libavfilter, ffmpeg and tools work has been done in FFmpeg. What you should know is that the current codebase of FFmpeg is messier compared to libav, but has quite a few more features, notably filters and more formats supported. Choosing one or the other gives you different set of features, but mostly different set of bugs and level of support of codecs. It's a big mess...

flihp 11y ago
Really unfortunate because the software is so useful.
- jacquesm 11y ago
  And that's probably one of the reasons for this whole debacle. A project without adoption would not be worth fighting over.
ux 11y ago
I'd be surprised if you had actually read the blog post I wrote (pkh.me) :) > most of the libavcodec and libavformat work has been done in libav Well, I believe this is a bit more complex. While it might be true for API changes and cleanups, FFmpeg has dozens of additionnal codecs and formats, as well as way more assembly/optimization code. > What you should know is that the current codebase of FFmpeg is a huge mess compared to libav Honestly, this is pure FUD and it's very surprising to read that from you. You seem to have no idea about the cleanups of FFmpeg because we do not advertise them (they are not relevant for the users). What is so much a huge mess? This is very insulting for the work done by FFmpeg developers these last years. Hey, even libmpcodecs (the MPlayer filter wrapper) is no more. A lot of work was also done on the documentation. Seriously, please stop doing FUD like this. > Choosing one or the other gives you different set of features Not exactly true.
- jbk 11y ago
  > I'd be surprised if you had actually read the blog post I wrote (pkh.me) :) I did, and many times. And I already said so. > Well, I believe this is a bit more complex. Unfortunately, it's more complex, yes, but it's not that much. Elenril, Koda and Martin are the one spending the more times and commits on libavcodec and libavformat. > Honestly, this is pure FUD and it's very surprising to read that from you. It's not. Unfortunately. Who has multiple implementations of the same codecs (2 prores decoders, at least 2 prores encoders) or libraries (2 resampling libraries) ? Who is spending hours removing the famous MPEG12EncContext from everywhere? And I don't even speak about the refusal to removing the non-working xvmc support for MPEG2. And sorry, but you are one side, that joined after the fork. Attacking me is not really objective. > Not exactly true. Of course it is. Every time I do package VLC I need to choose one fork over the other and every time that means a different bug. This is documented over and over on our wiki and our bugtracker... EDIT: I'm sorry you (and other) took that as an attack on FFmpeg. We use FFmpeg over libav in the current VLC windows and Mac version.
  - otis_inf 11y ago
    > Attacking me is not really objective. In the decades I'm developing software, I've learned that there is no developer out there liking somebody else's code. There's always something. You can think you're objective and unbiased, but you're not, no-one is. FFMpeg's code might be a mess due to a large chunk of legacy / backwards compatibility code, but very likely the other side's code base is a mess in other people's eyes.
emcrazyone 11y ago
" FFmpeg is a huge mess compared to libav" I assume this is an unbiased opinion as much as it can be but could you elaborate on what about FFmpeg is a "mess." I've used both these libraries in building MythTV from strictly a user perspective. Both code bases are open source. I'm wondering if there is so much turmoil here, why doesn't someone (like VLC) take the best features from both projects and create their own library? I never understood the OSS communities. It just seems simple to me. If you don't like it, fork it and do your own. <shrug>
- jbk 11y ago
  > I assume this is an unbiased opinion as much as it can be but could you elaborate on what about FFmpeg is a "mess." Examples: 2 prores decoders, 2 prores encoders (or 3), 2 different resampling libraries, libstagefright integration that does not work, more global context structures compared to libav, etc... They also refused to remove some very outdated (non-working) code like xvmc. > why doesn't someone (like VLC) take the best features from both projects and create their own library? Because it's a lot of work. An enormous work.
  - zvrba 11y ago
    Having multiple implementations of a feature does not make it a "mess" unless they step on each other's toes.
  - makomk 11y ago
    If I remember correctly, a big part of the reason that ffmpeg ended up with two resampling libraries is that after they'd created theirs, libav wrote their own with a different, totally incompatible API and ffmpeg wanted to support applications that were written for the libav API.
    - loup-vaillant 11y ago
      "There is a reason for everything" Scott Meyers, talking of the various… quirks of C++. https://www.youtube.com/watch?v=48kP_Ssg2eY https://www.youtube.com/watch?v=48kP_Ssg2eY
scrollaway 11y ago
The whole situation is really representative of the whole philosophy of doing aggressive cleanups/rewrites. Maybe it'll improve things on the very long term, but you will have a really, really long period where your product is completely unusable, and will drive a lot of pure frustration. I hope some big entity ends up throwing money at the situation, it seems fixable, just a lack of manpower to fix it. I mean, Google relies on it a whole lot for one.
shmerl 11y ago
With this change, is merging of the projects now a possibility?
- jbk 11y ago
  Let's hope so?
- aidenn0 11y ago
  Like jbk, I'd like to hope it will happen, but the combination of significant tribalism, plus the very different development philosophies may prevent this. For the merging to happen, there would have to be both some agreement on the technical direction of the two projects, as well as some sort of social resolution, which would likely involve some maintainers of one fork or the other leaving. Regardless, from my point of view, it seems unsustainable to keep on merging from libav to ffmpeg at the pace that Michael has been doing, so the projects will end up diverging enough at one point that momentum ends up behind one or the other.
bjourne 11y ago
Is the info about the attempted coup d'état wrong then? Because that's completely nasty. If you don't like the project leader, make a real fork and hope there is enough of you who will jump ship. Abusing the fact that you control the infrastructure to try and lock out the old leader is bad.
- jbk 11y ago
  > Is the info about the attempted coup d'état wrong then? It's partially untrue, yes. There was an actual vote from all the active developers to remove Michael from leadership, and that included the infrastructure developers. But yes, the fork was very badly done.
  - gillianseed 11y ago
    >It's partially untrue, yes. There was an actual vote from all the active developers to remove Michael from leadership, and that included the infrastructure developers. Then why did so many remain with the ffmpeg project instead of going with libav ?
    - Flowdalic 11y ago
      It appears the opposite is true. ffmpeg is more or less a one man show. See http://thread.gmane.org/gmane.linux.debian.alioth.multimedia-maintainers/37620 http://thread.gmane.org/gmane.linux.debian.alioth.multimedia... and https://lwn.net/Articles/650816/ https://lwn.net/Articles/650816/ "I think the statistics indicate that the situation is much worse than I expected. Please keep in mind that because of the daily merges, all commits that are made in Libav also appear in FFmpeg, but not the other way round. With a finger-in-the-wind estimate of subtracting the numbers in the Libav table from the FFmpeg table, the distance between Michael and the other FFmpeg developers because even more extreme."
  - Qwertious 11y ago
    What were the results of the vote? Are you saying Michael was voted out?