3 ms·

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 belie

by 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.
  - jbk 11y ago
    Except I'm on no side in this fight: we use both, have friends in both side, and we host FFmpeg's git. I may be not 100% objective, but I'm more objective than a developer from one of the side. The fork is hurting us a lot. It means a lot of work.
    - otis_inf 11y ago
      It might hurt you but it looks like it doesn't hurt you enough that you decide 'pick a side and stick with it'. What I don't understand is why you don't simply pick ffmpeg and be done with it? E.g. it's good enough for playing whatever format on windows using WMP, so why isn't it enough for you to play whatever is out there using VLC?
      - jbk 11y ago
        > What I don't understand is why you don't simply pick ffmpeg and be done with it? Because distributions have picked libav or FFmpeg. So we need compatibility with both.
        dvirsky 11y ago
        I was sure VLC vendors its own dependencies and is completely standalone, and doesn't need anything installed to work. TIL I guess.
        pgeorgi 11y ago
        distro packagers typically undo vendoring for lots of reasons (among others: smaller packages, fixes propagate automatically, which is particularly important with security issue) Given how similar libav and ffmpeg still are in places, they might even consider replacing the vendored ffmpeg with the packaged libav (or vice versa, if done the other way). But the fallout would be for VLC to deal with ("VLC breaks on my Debian, it must be crap").

by ux 11y ago

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.
- jbk 11y ago
  Except I'm on no side in this fight: we use both, have friends in both side, and we host FFmpeg's git. I may be not 100% objective, but I'm more objective than a developer from one of the side. The fork is hurting us a lot. It means a lot of work.
  - otis_inf 11y ago
    It might hurt you but it looks like it doesn't hurt you enough that you decide 'pick a side and stick with it'. What I don't understand is why you don't simply pick ffmpeg and be done with it? E.g. it's good enough for playing whatever format on windows using WMP, so why isn't it enough for you to play whatever is out there using VLC?
    - jbk 11y ago
      > What I don't understand is why you don't simply pick ffmpeg and be done with it? Because distributions have picked libav or FFmpeg. So we need compatibility with both.
      - dvirsky 11y ago
        I was sure VLC vendors its own dependencies and is completely standalone, and doesn't need anything installed to work. TIL I guess.
        pgeorgi 11y ago
        distro packagers typically undo vendoring for lots of reasons (among others: smaller packages, fixes propagate automatically, which is particularly important with security issue) Given how similar libav and ffmpeg still are in places, they might even consider replacing the vendored ffmpeg with the packaged libav (or vice versa, if done the other way). But the fallout would be for VLC to deal with ("VLC breaks on my Debian, it must be crap").