There is an old Saturday Night Live parody commercial from the later days of the U.S. phone company monopoly featuring Lily Tomlin as a phone company representative:
“So, the next time you complain about your phone service, why don’t you try using two Dixie cups with a string? We don’t care. We don’t have to. We’re the Phone Company.”
The reason I bring this up is because I participate in the FFmpeg project. FFmpeg is in a unique place among open source projects. Whereas, a common complaint against the open source paradigm is that there is too much duplicated effort among competing projects that all basically do the same thing while never matching or excelling beyond their proprietary counterparts, there is nothing else in the entirety of the software world like FFmpeg. Indeed, FFmpeg has a monopoly on do-everything multimedia manipulation programs.
Some people are distraught by this.
swfdec author Benjamin Otte has a blog post lamenting the problems of developing directly with FFmpeg. This finally prompted me to use my sucky research method against FFmpeg. The sucky research method works like this: Google for “XYZ sucks”, where XYZ is some software program, consumer product, or company in order to gauge the level of negativity against XYZ or perhaps to just commiserate with other chumps in the same boat as you. I most recently used this method to find other chumps as frustrated as me with both PHP and WordPress.
I discovered surprisingly few sites dedicated to hating FFmpeg. These stood out: FFMpeg strikes (again) and ffmpeg sucks. One comment even pointed out that there are no ffmpegsucks.tld domains registered yet, so I take that as a positive sign (hurry and register yours today!).
Most of the complaints center on the fact that there is still no central release authority or process for FFmpeg. My usual response to this is that the leadership of FFmpeg is committed to making releases eventually (this may seem non-committal but many people are still under the impression that the leadership is actively opposed to releases). It’s just that doing so takes work, planning and — get ready for it — testing. Honestly, why do you think I have been working on FATE? I want it to serve as a baseline to build confidence that the code, you know, actually works before we make any releases.
I’m not mad, though. It’s all right. I mean, seriously, what are people going to do about the situation? Refuse to use FFmpeg? Maybe fork the codebase? Heh, I dare you. FFmpeg is only as capable as the talent developing it. Better yet, is someone going to start a competing project from scratch to supplant FFmpeg? Seriously, get a grip and calm down before you hurt yourself, then we’ll talk about what we can all do together to improve FFmpeg and work toward a release schedule.
Unfortunately, we just got received a few thousand files that crash FFmpeg. That might push back the release schedule a bit. You want a reliable and secure multimedia backend library, I trust?
Related:
- The Intersection of Code and Money — examining how — and whether — financial sponsorship has helped FFmpeg
I like that post. (Adobe seems to have you trained well in PR work ;))
And to clarify, I do think that ffmpeg is great at what it does, which is (de)coding of my video streams. And it does that impressively fast. ote that I do look at ffmpeg source code for inspiration quite often. That fact alone is quite a testament to the code from my point of view.
But there’s some very important things I really dislike about ffmpeg:
1) The thing I blogged about: Not caring. While I as a GNOME developer got “trained” to talk to other people (distros, related upstream projects, normal users) and actively work out solutions to their problems with my code, I’ve always felt that FFmpeg is one of the worst projects at this. (Examples are not doing releases or the NiH towards the Xiph people – and no, the Xiph people aren’t saints either)
2) The aggressive community. Whenever I see something coming from the ffmpeg camp, it’s in a very aggressive way. I should note that this is not about meeting people, just the tone on mailing lists, IRC channels or in blog comments. This also has the unfortunate side effect that I do behave very aggressive towards ffmpeg as a result today.
3) Wrong priorities. In particular I think FFMpeg undervalues security and overvalues performance. It is in the happy position to usually only do reads on input data, so there’s a low chance the security issues are more than DoS by crashing, but whenever I advocated bounds checking after running zzuf over files, I got “no way, that slows it down” as an answer. Another wrong priority for me are NiH vs cooperation, but I mentioned that above.
PS: You forgot http://flickr.com/photos/38647526@N00/1043186989/ in your links ;)
Well, the problem with releases (also with MPlayer) is that everyone shouts how important it is but _nobody_ (no, really, check the archives, only hot air), really _nobody_ even wants to lift a finger to make them. The obvious conclusion is that these people can’t actually care that much, otherwise they’d surely at least do something?
Like talking to the distribution maintainers who already do “releases” and coordinate them or something.
Btw. what do you mean by NIH vs. Xiph? Xiph is (IMO very deservedly) “hate” for Ogg, but that is a minor thing.
If you mean reimplementing codecs, FFmpeg does that for basically anything, but in case of Xiph a part of the problem is that to my knowledge they never properly separated the demuxer and codec code, which means it does not truly fit into FFmpeg as-is.
Lastly, as for “security”: The way you summarize is inaccurate, DoS is lower priority in FFmpeg, not security issues in general, but if a comment like “no, this slows things down” came from Michael that usually means that his “educated guess” is that it is possible to fix _without_ slowing it down, and the issue you have IMO is more with Michael being extremely reluctant to accept hacks ;-)
And one last point about the NIH you perceive (and probably exists, but you are not very specific ;-) ): multimedia is one area where almost always only one implementation of things exists, a second implementation in FFmpeg can help improving specifications etc. and is not necessarily a bad thing.
Or there is other stuff like the AES code where the code to use the appropriate libraries almost needs more code than reimplementing it. Or one library having license issues and the other one not always being available.
Maybe these reasons seem/are silly in the long term, but it’s not necessarily as stupid as it looks from the outside.
Since I don’t (and probably never will) develop for or with it, I’m just happy a lot of QA is done – for instance, the Internet Archive uses FFMPEG to create most (all?) of it’s derivatives, and if that was untested and prone to doing odd things with input files, it’d be more trouble then it’s worth uploading odd file formats.
In any case, it seems in general there are problems, but I think anyone is lying to themselves if they can’t find problems with any project going on right now.
FFMPEG rocks!
I like it, and I also like their badass no-nonsense development culture.
:-)
Cheers
-Richard
@Otte: You have a funny way of showing how you “got ‘trained’ to talk to other people” by posting an insults to Plant Gnome.
If I didn’t care, why would I have posted on a comment on Dave’s blog telling him to install libswscale-dev to get the missing header?
@Alex: don’t follow his example of blowing things out of proportions.
Or as my German teacher said: remember that exaggeration is s stylistic device ;-). People (over-)use it all the time to get a point across.
I was just looking for a statement of why it would be a good idea for me to download, install,and use FFmpeg. What would it do for my next task, recording my 78 rpm records?
Eldon.
Yes, it sucks.
If FFMpeg is so great, why do half the documented options fail with a “Output file #0 does not contain any stream” error?