Hacker News Reader

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.

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.

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

> why doesn't someone (like VLC) take the best features from both projects and create their own library?

Because that in itself would be a huge project, with moving targets as the source projects develop over time. If it were that easy the VLC people would just implement everything themselves and not need either 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.

The problem is, of course, the humans.

People sometimes take things very personally even when not meant that way. A significant fork for no good reason can distract from the work of the core project and dilute the user-base, and people will not always agree on what a good reason is/n't. Sometimes the problem is stated as poor code and/or procedure quality, and this can be taken as a rather direct insult.

Sometimes massive forks happen because of differing priorities between different groups of people and everything is perfectly amicable - you don't hear about these cases much (unless it inconveniences the userbase) because there is no drama to make a noise about. Sometimes these forks later re-merge, sometimes one becomes clearly superior and the other fades out, sometimes they go on to be completely separate projects.

It sounds like three are personal issues involved in this particular mess that we don't exactly know about so can#t hope to fully understand because the discussions started in private and have not been published and as we all know any argument, especially one that has gone on for some time, people can lose track of the true chronology of the issue and that can make reconciliation near impossible.

I agree with everything you say however, if the two things you rely upon are, in their own words, such a mess then I have to imagine that mess consumes an equal if not more inordinate amount of time to integrate with.

I'm a software developer too. In my career I've had to implement logic to work around buggy libraries, spend time looking into bugs in others code... It seems that at some point that the means don't justify the end and having my own code base that I'm familiar with would be easier than fixing theirs and waiting for disputed parties to figure out what they are going to do.

And I never claimed doing your own was easy. All I'm suggesting is that at some point it's easier than dealing with what you got.

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

For what it's worth, a lot of production code looks this way. It's not right, it really should be nice and neat and so on. However, I don't see it as a grave sin against the project. Messy code can diverge where needed more easily.

Three different copies of the same code? Yeah, ok. That's ok. One day, when you can, merge them together. You can't merge them together? It's ok. Maybe they shouldn't be merged together.

Is it a barrier to entry for new developers? I feel that any developer who has worked on messy legacy code won't bat an eye. This sounds more like a problem experienced by a young coder fresh out of university.

You definitely can write clean code. Cleanliness can be a priority. There are some surprisingly clean and well-written large codebases out there. However, a lot of people just don't care. They are very smart, capable people who just bang out code that works and don't care to integrate in the proper clean way with the old code.

If you want clean code, an old, large, working C/C++ codebase is not what you want. We often can't spend time cleaning up old code, since there's always more features to implement, bugs to fix, etc. Learn to deal pragmatically with code like that. It's not like that out of malice, or some misguided attempt at writing the largest IOCCC winner. You can work with it. It's just a bit trickier.

I've worked on some of those "old, large, working C/C++ codebases" and the ones that are not clean are the ones where you are terrified of making a small change to fix a bug, especially close to release, because you have absolutely no idea what might break. Two copies of the same code? Great, which one do I fix? Both? How do I test that it worked, I can't even figure out where #2 is activated in the UI?! Is there something a little different about them that I need to watch out for? And test cases for said codebase? Hahahahaha!

Writing clean code is not an academic exercise. It means comprehending it takes longer, writing features takes longer, testing it takes longer. It makes every interaction with the codebase harder.

That might not be quite as bad in a proprietary codebase since you have somewhat more of a captive audience, but in an open source project where you want a long-tail of contributions from many people, that is a serious problem.

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.

"There is a reason for everything"

Scott Meyers, talking of the various… quirks of C++. https://www.youtube.com/watch?v=48kP_Ssg2eY

Having multiple implementations of a feature does not make it a "mess" unless they step on each other's toes.

I never understood the OSS communities. It just seems simple to me. If you don't like it, fork it and do your own.

https://xkcd.com/927/

> If you don't like it, fork it and do your own.

The issue is the "you" implied there. So you fork it and start working on your own. What do the other contributors working on the previously-existing project do?

This seems to resolve itself when there's a clearly superior project and developers and distributions switch to the newer project.

However, if both projects continue to simultaneously develop...

> 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? These days I just use gStreamer which can wrap either one in a sane API and is 1000x easier to extend.

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.

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

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

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

What were the results of the vote? Are you saying Michael was voted out?

Really unfortunate because the software is so useful.

And that's probably one of the reasons for this whole debacle. A project without adoption would not be worth fighting over.

With this change, is merging of the projects now a possibility?

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.

Let's hope so?