On Mon, 31 Aug 2015 11:49:19 +0000 (UTC) Carl Eugen Hoyos <ceho...@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. > 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@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
