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

Paul B Mahol onemda at gmail.com
Mon Aug 31 15:17:33 CEST 2015


On 8/31/15, wm4 <nfxjfg at googlemail.com> wrote:
> 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
> filters.

There are no duplicated filters AFAIK, there is only interlace - failed
attempt to LGPL part of tinterlace, which was and is really bad idea.
(There was other ways to LGPL that functionality.)

>
>> 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
>    them.
>
> 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).
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


More information about the ffmpeg-devel mailing list