Comment by ux | Hacker News Reader

Comment by ux | Hacker News Reader

Parent Full thread

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.

> 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.

> 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.

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.

First thing I thought of: https://en.wikipedia.org/wiki/False_balance

Given what I've read from the stories, and taking into account the rhetoric employed by one side versus the other, I have to say that, at least in tone, FFMpeg struck me as being more mature about the whole affair.

> I have to say that, at least in tone, FFMpeg struck me as being more mature about the whole affair.

same here. And regardless of what their codebase smells like, their stuff works and does what it says on the tin, letting people play whatever format there is out there on a massive amount of different systems. I'm the first to admit the dialogs they're using to configure the codecs is one which is a yearly 'Ugliest UI' award winner, but luckily others have made front ends which make you avoid all that mess in the first place.

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?

> 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.

I was sure VLC vendors its own dependencies and is completely standalone, and doesn't need anything installed to work. TIL I guess.

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").

You mean, on WIndows they e.g. use FFmpeg and on mac Libav (example, I don't know what they pick) ?

On windows and mac VLC uses ffmpeg. On linux and co, it uses whatever is there in the distro.

Reply on news.ycombinator.com