Dave, It’s dead simple. FFmpeg developers do not care about you – or anyone else. The only thing they care about is sitting in a cave admiring their awesomeness.
I’d suggest you go and file a bug with VXL and tell them that their ffmpeg handling is wrong (as they linked to and not forked it). While doing this, suggest to them that they might wanna use GStreamer (or Xine or whatever) instead, as those projects provide stable API and are actually more powerful.
In Swfdec I’ve seen the light and removed the ffmpeg option. They don’t care about me, so I won’t care about them.
Or to paraphrase: There’s always the ffmpeg solution to every multimedia problem — neat, plausible and wrong. Or did you pad and align your buffers?
13 comments ↓
> FFmpeg developers do not care about you – or anyone else. The only thing they care about is sitting in a cave admiring their awesomeness.
At least FFmpeg developers review patches in a timely manner. I’ve seen patches sit in the Gnome bugzilla for years without a human review. Might lead some one to say “Gnome developers do not care about you – or anyone else. The only thing they care about is sitting in a cave admiring their awesomeness.”
… doesn’t gstreamer provide options for a large variety of codecs via gstreamer-ffmpeg?
Not that making it SEP isn’t a valid development strategy.
“While doing this, suggest to them that they might wanna use GStreamer (or Xine or whatever) instead, as those projects provide stable API and are actually more powerful.”
This isn’t really true, or more accurately, they do rather different things. ffmpeg is a collection of decoders, many of which have no alternative free implementation. Xine and Gstreamer would play a lot fewer videos than they actually do, if ffmpeg (and gstreamer-ffmpeg) didn’t exist.
Alex: ffmpeg is one thing, GNOME is a collection. Your statement is wrong for the patches I receive. Please be more careful when trying to troll.
Adam Williamson: not so easy. In my opinion, ffmpeg has hintered *proper* development of free decoders/enconders of these formats. Everyone hacks on (literarly) on ffmpeg and no one is interested in proper and tested way of doing things.
Users may like ffmpeg devs, but other devs have huge problems of “we-won’t-do-stable-release-ever” attitude of theirs.
He was missing swscale-dev, it’s a simple case of pebkac, presented as a ffmpeg problem. Blaming ffmpeg for everything and the kitchensink is about the lamest thing you could do, especially given how dependent everyone is on their codec (and muxing format, for some projects) implementations.
Ffmpeg has broken their public API/ABI once in the past ~2 yrs, going from v51 to v52 in september ’08. That was properly announced on the developer mailinglist and website. That is better behaviour than the kernel. Don’t be so negative.
Adam: GStreamer and Xine are the better ooptions because they do as much as ffmpeg (as they use it) and more, like for example providing a stable API and caring about their users. Which is why I suggested using it instead.
GStreamer also adds dynamic codec installation or patent problem avoidance to the game, which ffmpeg doesn’t offer. So from my POV ffmpeg is just worse.
Ronald: No, that’s an ffmpeg problem, just because it didn’t only happen to Dave, but because it happens all the time. If ffmpeg cannot make it easy to write a configure script, it provide a crappy API (hint: an ffmpeg.pc would be nice). Also, they broke API way more often, because I remember people shouting at me from Gentoo, Debian, and wherever else when I still used it.
Benjamin: ffmpeg provides (and installs, unless the package is broken) separate libavformat, libavcodec, libavutil and libswscale.pc files.
The broken API may be becuase of improper API use in projects, such as using private functions (not prefixed by av_*()) or stuff like that. You may be directly accessing codecs or codec features that don’t yet exist, you may be statically allocating variable-size structures (new members are continuously added at the end, hence the existence of all av_*_context_alloc() functions), and there’s a bunch more of these options. If used correctly, ffmpeg is API/ABI-stable. The adding of new items (and because of gobject, the not accessing struct members directly) is used more widely than just ffmpeg.
The public API and ABI was never broken over the past 2 yrs, until September ’08. The new API/ABI will be in place for the coming 1-2 yrs. This is the direction glib/gtk also discussed taking, and the kernel takes a similar approach. It needs to be broken occasionally for new features that weren’t taken into account in the old API.
Here’s my suggestion: instead of seeing an ffmpeg problem and just blaming an pointing fingers, why not try to understand the problem at the developer-level (you’re very, very smart, you’d have no problem whatsoever) and then try to see where the problem really is? You’ll notice that personalities aside, the problem is usually in the application, not in ffmpeg. If you can point at the exact problem, it’d actually be helpful because ffmpeg developers can fix their mistakes. And they will. Right now it’s just blaming and pointing fingers and this bidirectional hate makes the working situation worse, not better.
bkor: FFmpeg is a collection of libraries, and a collection of developers. Some of the developers do their best to help users who are having trouble. If you limit your complaints to specific individuals like Michal, then I will limit mine to specific individuals like Vincent.
otte: FFmpeg provides a a .pc file for each of its libraries (libavformat, libavcodec, libavutil, and libswscale.pc). complaining that their is no ffmpeg.pc is like complaining that their is no gnome.pc.
As far as the situation this week goes, VXL probably should have stopped in configure and asked Dave to install libswscale-dev.
Ronald: agreed
And everyone please try to understand, ffmpeg only has a handful of active developers. The most knowledgeable of which has specific was that he like to do things just like a Drepper (who also doesn’t make releases, though he does make branches) or De Raadt. Due to legal fears, it doesn’t get nearly the amount of corporate money as Gnome. It’s biggest user, YouTube won’t even acknowledge that it uses it.
otte: if you meant it that way, then sure. But then, that’s kind of the purpose of ffmpeg – they intend to provide a collection of codecs to be used by other projects. It’s fine to say “it’s better to use gstreamer or xine for purpose X than using raw ffmpeg because they provide a richer, stabler interface”, but it’s not really fine to finish with “…so FFMPEG SUXORS!”, because to a large extent, gstreamer and xine can only do that because ffmpeg does such good work on the codecs. It’s being deeply ungrateful to the guys who do a lot of hard work on the codec.
Yes, it would be nice if they’d do proper releases with proper API/ABI stability guarantees. Believe me, I package or help to package several things which use ffmpeg, so I know that (it’s probably worse for packagers than developers). But I’m not going to sit here and tell them they SUXORS just because they’re not perfect. Just like I won’t say gstreamer SUXORS because its codec compatibility is not yet anywhere near ffmpeg’s.
unrelated to anything current
does swfdec support rtmp? will it?
Adam: You pretty much say exactly the same as me. Devs should try to avoid using ffmpeg and use something else instead. Plus: I didn’t say ffmpeg sucks, I said they don’t care about you.
noname: Yes it will. Swfdec will support everything Flash files need. And RTMP is part of that. Besides, it’s what I’m hacking on right now.
[…] author Benjamin Otte has a blog post lamenting the problems of developing directly with FFmpeg. This finally prompted me to use my sucky […]