On 8/31/15, wm4 <nfx...@googlemail.com> wrote: > 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.
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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
