[FFmpeg-devel] [PATCH 1/2] avcodec: Add interface to motion estimation

wm4 nfxjfg at googlemail.com
Mon Aug 31 14:56:19 CEST 2015

On Mon, 31 Aug 2015 11:49:19 +0000 (UTC)
Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:

> Ronald S. Bultje <rsbultje <at> gmail.com> writes:
> [...]
> If this were all true, why don't you fork FFmpeg 
> and show us how it's done better?

Don't even go there.

> Seriously: No matter which fair I visit, the users 
> always tell the same story. They liked avconv 
> because it promised so many things that could be 
> improved in FFmpeg and quickly switched, but in 
> the end they had to switch back to FFmpeg: Not 
> necessarily because of the bugs (they could 
> backport the fixes) but because of the missing 
> APIs (like VDPAU).

Pure bullshit. avconv added vdpau support before ffmpeg - ffmpeg merged
this. If you mean the vdpau legacy APIs, they're finally removed. And
they deserve to be removed, because they're bad. (Remember the
per-codec pixel formats? Ridiculous.)

For the record, many good cleanups (and also features) came from Libav.
FFmpeg on the other hand made the mess worse. Just look at abominations
like CONFIG_INCOMPATIBLE_LIBAV_ABI, or the really messy way the old
vdpau API was kept alive, which required hours of cleanup just to make
the version bump guards working. And all the duplicated codecs and

> I mean of course this all sounds incredibly 
> promising and while I found it far too good to be 
> true when you originally suggested it I couldn't 
> know for sure - after all, you could have been 
> right and succeed with the promises made. But why 
> you are still suggesting the same thing after 
> four years of undeniable proof that it is not 
> working is beyond me...

After reading BBB's post, this seems to refer to Libav's attempt to try
cleaning up the code, instead of merely piling hacks upon hacks. I'd
say it was very successful. For example, we now have reference
counting, which our dear project leader almost didn't merge (there was
a post full of FUD that claimed this would cause "speedloss"), but in
the end merged anyway, because FFmpeg _needs_ the stream of patches
coming from Libav. Even though people like you exist.

Oh yes, politically Libav wasn't successful. But that's politics. Keep
in mind that FFmpeg merged _everything_ from Libav, so just stop the
hypocrisy, ok?

> I really don't understand why we don't spend 
> the time fixing real (user-reported) issues 
> instead of discussing how "clean" an api can 
> be...

Because an unclean API means it will be harder to use? Less robust? More
bugs? Do you want a hard to use, buggy API? Then by all means, never
try to improve anything. Why do we even have to argue about whether
it's good to improve something?

Let me remind you that ffmpeg is notorious for having a hard to use
API. And the mistakes I see API users do are because of weird, shitty
things someone once thought were a good idea, and which we now have
a hard time to fix.

So there are 3 ways to fix something:
1. Never change the API. Well, now you can't fix the API, have fun.
2. Add new APIs and maintain the old APIs concurrently. You will have
   to maintain a dozen of API revisions, and users will also have to
   deal with an API that provides the same thing under dozens of
   APIs. What could possibly go wrong?
3. You add improved APIs, deprecate the old ones, and finally remove

Which do you pick? If it's 3, what is your complaint again?

The mess also slows down FFmpeg development. How can someone improve
anything, if you have to fight with dozens of weird things? Imagine
someone, a long time ago, added a small special case to fix a single
sample (which was probably a broken sample in the first place). And
then other developers came and added other special-cases on top of it.
And these special-cases interact in weird ways, and users will add
weird code to their applications to take care of this, and everyone
depends on it, and changing a small thing will break everything else,
and then you realize YOU CANT FIX THIS SHIT and then you just use
gstreamer. Actually, nobody enjoys dealing with an entangled,
unmaintainable mess. (Except some ffmpeg devs, apparently.)

Anyway, now imagine someone trying to fix an issue, like the API not
making sense in a specific case and requiring workarounds in
application code. Almost impossible, because the FFmpeg code wasn't
designed with clear, simple concepts in mind, but was created from
years of piling hacks upon hacks.

Think of every corner case and exception in the code as a speed-bump for
developers (especially new contributors) trying to write useful patches.

I hope I explained it well enough that even someone who only posts
single-line patches (of the form "if (x==0x123mysample) hack();"),
instead of attempting to fix deep-sitting architectural problems (like
certain Libav developers do).

More information about the ffmpeg-devel mailing list