[FFmpeg-devel] [PATCH 1/2] avcodec: Add interface to motion estimation
wdlkmpx at gmail.com
Tue Sep 1 17:11:14 CEST 2015
This discussion again hehe. I'm just a user and I don't think a
reunification is possible, I was reading the gentoo forums and it
became a flame war between users, most of them bashing Libav. Though I
like the name "libav" better.
The way Libav started, it was clear that it was not a fork, but a
replacement, something meant to put and end to ffmpeg immediately, so
it needed a purely political position. A fork must rename its
applications AND libraries, so both original and deritive works can
coexist peacefully and users can choose what is best for them.
On 9/1/15, wm4 <nfxjfg at googlemail.com> wrote:
> On Tue, 1 Sep 2015 07:50:15 +0000 (UTC)
> Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
>> wm4 <nfxjfg <at> googlemail.com> writes:
>> > Oh yes, politically Libav wasn't successful.
>> Just to make sure I don't misunderstand you:
> Oh come on, you misunderstand intentionally anyway.
> Or does Hanlon's razor come into effect?
> I really don't know what puts your hateful, ignorant posts into a
> better light.
> Maybe you could just try to make a real effort at reconciliation once,
> or even just understanding your opponent?
>> Gentoo and Debian did not switch from avconv
>> to FFmpeg for technical reasons, but only for
>> political reasons?
>> And, consequently, the changes from FFmpeg to
>> avconv were purely technically and not politically
> Actually, most issues were probably caused by comparing ancient
> distro-packaged avconv versions to very recent ffmpeg releases (because
> especially Debian and Ubuntu really love... erm... packaging old
> software, and also slower Libav release cycles).
>> > Keep in mind that FFmpeg merged _everything_
>> > from Libav
>> I believe you know very well that this is not true.
> Oh, but it is true. Definitely. It's a fact. Some things were undone on
> merge, or parked as components not used by default (like duplicated
> encoders), but in the end basically everything was merged. Especially
> the beneficial changes. I haven't heard a single acknowledgment from
> you that Libav did good changes that were useful to FFmpeg too.
> Don't go around and spread lies (even if by omission). You're being
> incredibly dishonest.
>> And I find it funny that you wrote a long
>> justification above why everything had to be
>> merged and here, you use it as an argument why
>> FFmpeg is bad (that's at least how I read it).
>> I was always very angry reading this argument
>> in your blog post and I always thought you are
>> among the strongest supporters of avconv. Funny
>> that this very blog post was one of the main
>> reasons why the distros switched...
> I don't have a blog and never had one. What the fuck are you even
> talking about?
> Your verbal "tic" of calling Libav avconv is also one of those WTFish
>> > 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?
>> In reality, it is of course 3, but as said above,
>> users switched from avconv from FFmpeg because we
>> tried to do 2, so it cannot be as bad as you paint
> But you agree that 3. is best? So what do you want to keep doing? Do
> you admit that 2. is not ideal? If so, why did you try to pursue it? To
> "beat" Libav? That would explain a lot of bullshit that was defended
> for political reasons, even though it was technically terrible.
> (My favorite thing is still the optional Libav ABI support.)
>> But I believe this was not the issue in this thread
>> > The mess also slows down FFmpeg development.
>> So do you want faster or slower development?
>> I fear you will have to decide...
> Faster of course, but not by just allowing low quality patches in for
> the sake of quickly adding obscure features.
> In fact, the goal is having an easily hackable codebase, so that
> contributors actually have it easier to write good patches, instead of
> having to write horrible hacks to reach their goals. Can you understand
> this statement?
>> I don't really understand the rest of your post,
>> but it sounds very, very similar to what you
>> suggest so strongly (and with changing arguments!)
>> to "fix" your issue yesterday;-)
> If you mean the alpha issue, the only reason you rejected this change
> was because it was "slow", without even providing numbers.
>> In the end, there is only one question remaining:
>> If avconv did such a wonderful job, why didn't you
>> support them? Don't you agree (now) that they would
>> have needed it?
> I did send patches to Libav.
> But I guess by "support" you mean taking politically position for Libav
> and against FFmpeg. Sorry, but not all people are like you.
> (Also, didn't you write above that you always thought I was a strong
> supporter of Libav?)
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel