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. On 9/1/15, wm4 <nfx...@googlemail.com> wrote: > On Tue, 1 Sep 2015 07:50:15 +0000 (UTC) > Carl Eugen Hoyos <ceho...@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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
