FFmpeg Developers Just Forked As Libav | Hacker News Reader

FFmpeg Developers Just Forked As Libav

phoronix.com

46 pointsdreur19 comments

In the age of git and hg, why is a fork such a big deal? Code can still flow fluidly between multiple forks of a project with almost no friction. Some amount of forking is probably healthy in the long run, allowing a different part of the community to take the lead and head in their own direction.

In the extreme, if everyone works on an independent fork, and never merges, we lose the benefits of building "team-sized" projects. But that does not seem what is happening here.

The friction isn't in the movement of code, it's in the movement of ideas and prioritization. Adding functionality, cleaning up the code, etc. When a project's contributors disagree substantially on how a project should be run, where the priorities should be, etc. then there can be a significant amount of friction just in day to day operations (like communicating about ideas on the mailing list).

Perhaps some of the fixes from libav can be brought back into ffmpeg, but eventually people will want to standardize on one or the other, and if the libav folks are splitting off because they want improvement, revitalization, etc. and the old guard doesn't, then I suspect people will move to libav instead.

Similar issues happened in the past with xorg (where XFree86 was mismanaged and eventually the community had enough and decided to fork it and fix it) and with KHTML/WebKit (where Apple forked it and made so many improvements to it that WebCore/JavaScriptCore have replaced KHTML in most (all?) projects (including Qt). That split wasn't a philosophical/managerial split, mind you, but the end result was the same.

The threat of developer and user drain is real. Forks can be good if a project is 'dead' or devs want to push it in a significantly different direction. But two forks that are similar and competing create subtle incompatibilities that force a developer to waste time doing something twice or, worse, add a feature/patch to only one branch and not the other. I would find it difficult to claim that code could flow "fluidily" between two forks -- forks are by definition different codebases and will always require extra work to cross-develop for.

This guys are horrible with names. Come on, libav, REALLY?

Seems to make sense to me. "Library audio/visual." If you're preparing to use libav/libavcodec and expect it to be user-friendly this is the least of your problems.

It's a superb name for an audio/video library.

FFmpeg has to be the best example of OSS done wrong. While it is incredibly powerful in what it can do and is overall a great project, it is crazy difficult to get it to build right, documentation of anything is scattered across newsgroups, the developers are always having arguments like this lately, and the API has breaking changes all the time, including completely removing functionality without any sort of replacement.

There is a fair bit a developer churn, the project doesn't have very strong leadership, and the source code is messier than it should be.

Let's just say my experience was less than perfect. Add to that language barriers and it is just a very hard project to work for.

Of course, projects like VLC and mplayer still get a lot of the credit for the hard work that FFmpeg is mostly responsible for.

You are unfair to VLC and MPlayer. Developers from VLC and MPlayer are contributing to FFmpeg quite a bit, and especially more than people from Chrome, for example...

And the countless crappy paid windows video converter apps that don't credit FFMpeg and all they do is do shell out to ffmpeg. I get a chuckle out of the the FFMpeg wall of shame (which is honestly smaller than it should be): http://www.ffmpeg.org/shame.html

I'm almost more OK with that than the VLC people. It's not that I have anything against VLC, but they recently did an AMA on Reddit and it kind of rubbed me the wrong way. The primary thing the VLC team gets credit for is being able to play pretty much anything you throw at it, but that's the product of a lot of DSP work that me and mostly a ton of other people a lot more talented than me did. If VLC came out and said "we make graphics frontends and command line options" that would be one thing, but there was a trend to accept the praise without coming out and saying that they weren't responsible for most of the work. It was especially frustrating for me because I actually dislike a lot of the UI/UX decisions that VLC made, which was their primary contribution to the media player.

I understand it when unscrupulous people rip off FFmpeg, but I had hoped there would be more honor among fellow OSS developers.

Please, stop spreading FUD.

First, we didn't do an AMA on Reddit.

Then, the UI/UX part of VLC is around 1/30th of the VLC codebase (not counting external libraries) and most of the code is demuxers, decoders, protocol handlers (all custom), video outputs, video filter, clock, audio filters and libraries wrapper (not only libavcodec).

Did you actually look at the codebase before saying things like this?

Then, VLC developers have worked on libavcodec, like for DxVA2 acceleration, and have been telling people to add codecs inside libavcodec, and not directly VLC.

> there was a trend to accept the praise without coming out

Where did you see that "trend" ?

Finally, I don't see what your work is on FFmpeg or other such libraries.

Edit: You know what, just disregard my first comment. It's mostly me being bitter and isn't productive at all. The solution is to have the projects work better together, not whine about who deserves the most credit.

I apologize, you're right. I actually went back to look at it and it was all non-VLC people misrepresenting FFmpeg and VLC.

I didn't mean to say that VLC doesn't do anything important, I just felt that FFmpeg gets less credit than it deserves because it is less user-facing.

As to the codebase and FFMpeg contributions: I actually have a patch sitting around that makes substantial bug fixes and improvements to the OS X VLC. Part of this was a result of my work in FFMpeg improving crash and corruption resilience. I wouldn't have worked on this if I didn't feel that VLC is a good project, so I apologize if you thought my comment misrepresented the project or the developers. It was simply meant to express a general frustration at the lack of recognition of FFMpeg developers.

Apologies accepted :D

We've tried to give more FFmpeg visibility, by adding badges to ffmpeg.org from our website (but this is on hold, because of the fork and the logo dispute), and we've reworked our about:box to show it more...

But, the truth is that the actual reason we want to find a business model for VLC is that we want to pay FFmpeg developers to work on FFmpeg.

If you have patches for VLC on OSX, please share, we need help on the OSX version of VLC.

If you have patches for VLC on OSX, please share, we need help on the OSX version of VLC.

It's complicated, but I'll try to talk with you out-of-band on this soon. Lately it seems like I have out of date patches just piling up all over my system for every project under the sun.

Almost all of the apps in the video category on the Mac app store are the same.

Try compiling it on Windows using cygwin with x264 enabled... I literally spent an entire workday on it. It was not fun.

That's a half the time it took me. I had to apply patches from news groups and take MingW headers from CVS (because the official release broke the build).

On the other hand, once I compiled the libraries, I had no issues interfacing it with code in Visual C++ \C#. The source files are fairly clean and documented enough that I could mostly figure out what to do by looking at the code.

Yeah I went down this route and lost a lot of time also. I ended up cross compiling it for windows on ubuntu and it has worked out well enough but even that took nearly 2 days to track down how to do it and then add the filters and plugins I needed (for doing things I took for granted as being easy like video rotations, overlays, etc).

Reply on news.ycombinator.com