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

[Ganesh Ajjanagadde]

On Tue, Sep 1, 2015 at 8:11 AM, shen long <wdlkmpx at gmail.com> wrote:
> 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.
>
> https://forums.gentoo.org/viewtopic-t-1010096.html
>
> 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.

This discussion has gone way off topic.
Please start a new thread if you want to discuss ffmpeg/libav,
and don't feed the flames.

>
>
> 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
>>> motivated?
>>
>> 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
>> things.
>>
>>> > 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
>>> it.
>>
>> 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
>>> afaiu.
>>>
>>> > 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
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel