[FFmpeg-devel] [PATCHv3] On2 VP7 decoder

wm4 nfxjfg at googlemail.com
Sun Mar 30 11:04:07 CEST 2014


On Sun, 30 Mar 2014 10:14:47 +0200
Vittorio Giovara <vittorio.giovara at gmail.com> wrote:

> On Sun, Mar 30, 2014 at 12:31 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Sat, Mar 29, 2014 at 05:24:03AM +0100, Vittorio Giovara wrote:
> >> On Fri, Mar 28, 2014 at 3:14 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >>
> >> You definitely are a Libav user, as is every ffmpeg developer and
> >> user, as you merge every day whatever change Libav provides.
> >> The fact that you can accept
> >
> > thats a game of words where you use a different definition of user.
> > also called a strawman argument
> 
> No, you decided to be a Libav downstream (and can't deny that) but
> take any occasion to bash Libav itself and its developers. You don't
> like that, so you have no other option than insulting and criticizing
> Libav devs (like you do below), so maybe it's you... grasping at
> straws ;)

So FFmpeg is a Libav downstream? That's pretty fascinating when looking
at it as a troll. After all, Libav was the project that aggressively
tried to replace FFmpeg (and succeeded to do so in some Linux distros).
You also banned the main FFmpeg developer from the libav-devel IRC and
mailing list. So I don't think treating FFmpeg as a "downstream" is
quite right, nor is thinking that Libav is a good upstream.

I think the better description of the situation is "two forks which
fight each others". Yep, that sounds accurate.

> > Noone disputes that people using FFmpeg also use code developed by
> > libav developers but that doesnt imply that they use the
> > unmodified libav.
> 
> Say what you want, ffmpeg is still behaving like a bad downstream that
> doesn't propagate patches upstream and harms users and devs for its
> own childish benefit.
> 
> >> > I did very rarely test it for sake of an argument or for some
> >> > statistics only ...
> >> >
> >> > So really the only place i could find an issue is in ffmpeg and
> >> > if i do, it goes either as bugfix patch to the ML, as bugfix commit to
> >> > git master, as ticket to trac or on my todo list for doing one of the
> >> > previous once i have time
> >>
> >> The point is that this daily merge from Libav to ffmpeg also allows to
> >> fix bugs sometimes and this is good, but the problem is that these
> >> seldom bugfixes remain here while they should be reported to the
> >> original author at least. This should be done in the spirit of open
> >> source contribution, not in the "my project has more features and more
> >> bugfixes".
> >
> > Lets see
> > FFmpeg merges from libav the commits as they are and we fix issues
> > in them as seperate commits on top of that. Keeping the code that
> > was taken from libav and each change on top of that seperate.
> 
> And, don't forget, you are also increasing your commit count so you
> can brag that ffmpeg has higher number of commits and (more
> importantly) you're not sending the patches upstream where they could
> be shared with other users.

Last I counted ffmpeg actually did have a slightly higher commit count
when subtracting Libav merges ;)

> > OTOH
> > Libav takes code from FFmpeg and rebases and stashes fixes and
> > improvments together so that noone can afterwards easily see what was
> > changed and why.
> 
> Nice troll attempt, but won't work. Rather than having an horrible
> source history like ffmpeg where you see every commit alternated with
> a merge (btw why the name qatar? are you afraid to use Libav name?)
> and makes git blame/history tracking MUCH harder, Libav prefers to
> have linear history with *single* *atomic* patches (as much as
> possible). This is so that you can see what's changed in a single
> revision, rather than having to navigate countless (and possibly
> distant) commits.

I agree that merging isn't really appropriate anymore. git was never
made to treat the case of merging two projects which keep diverging.
It's also painful that merge commits contain "additional" changes you
wouldn't expect there. Cherry-picking would be much better.

"quatar" AFAIK comes from an april joke on Libav's website a few years
ago. And yes, it's stupid.

> > Just as an example from the last 2 days you can take a look at:
> > The brender pix decoder in libav:
> > https://github.com/Libav/libav/commit/ae17878fb2ab100264226c84c58f5b95a703312f
> > compared to the original that was in ffmpeg before:
> > https://github.com/FFmpeg/FFmpeg/blob/68014c6ed98b5c90f4dc211429dd269ac727be4b/libavcodec/brender_pix.c
> >
> > FFmpegs changes on top of what i merged back from libav:
> > https://github.com/FFmpeg/FFmpeg/commits/bcd5fd5346be263162792be595eff9fc08e5c853/libavcodec/brenderpix.c
> 
> Yes, you're welcome for my bugfixes, no need to thank me.
> 
> > so really, libav seems trying very hard to make their changes unuseable
> > by ffmpeg while OTOH it seems seperate commits for each fix in ffmpeg
> > arent enough for libav to use them.
> 
> Oh, they are quite useful to you, otherwise you'd not spend so much
> time merging them. At the same time merging makes backporting *much*
> harder so that Libav cherry-picking from ffmpeg takes much longer than
> merging from Libav. So kudos, I guess?

I'm not really sure what you're complaining about. Merging Libav
changes to FFmpeg makes cherry picking FFmpeg changes and porting them
to Libav harder?

So what do you want?

After all, we're all interested in improving the situation.

> > its probably not very diplomatic but IMO, if you fork another project
> > you should accept that if you dont merge all changes that you wont
> > have all changes then and that the extra work that choice causes is
> > your problem.
> 
> Maybe you have a different definition of "fork", but the kind of fork
> that took place between ffmpeg and Libav means that the two projects
> didn't want to deal with each other any more. Libav mostly complied
> with that, whereas ffmpeg seems to be leeching on every change brought
> in by it, complain about it, and then not sharing the features or
> bugfixes with it.

Wait what. Libav didn't like FFmpeg's maintainer (MiNi), and that's why
they split off. FFmpeg soon started to merge Libav developments, but
Libav on the other hand pretended that FFmpeg didn't exist.

And guess what? That's the ONLY reason the FFmpeg and Libav sources are
so different right now.

It seems to be a recent trend that security fixes and even features are
merged to Libav. That's a good thing, but also shows how Libav used to
not care about FFmpeg stuff.

> The open source movement is successful because of sharing and of
> diversity, not conformity and silly competition. Maybe you should be
> accepting the fact that ffmpeg is a Libav downstream and either stop
> merging code and live on your own or start sending patches for the
> benefit of both projects.

Well, the competition between Libav and FFmpeg actually had some
positive effect, though I'm not exactly sure how it compares to the
damage of having two libraries pretending to be the same thing, while
actually being very different.

Please stop thinking of FFmpeg as a downstream. The main reason that
some developers don't sent patches to both projects are:
1) The code is sometimes very different.
2) FFmpeg often provides additional features, which some new patches
   depend on, so applying the patch to Libav is actually work.
3) It's a pain to go through patch review twice.

So this has nothing to do with being upstream or downstream.

What do you want? That MiNi ports all FFmpeg contributions to Libav,
and sends them as patches to libav-devel? That's ridiculous, even if
you ignore that MiNi is (probably) still banned on libav-devel.

> > And yes i would suggest that all libav developers just join ffmpeg,
> > end the split and noone has to do duplicate work, testing and
> > reporting.
> 
> Cool, that must be the reason why every new Libav contributor gets an
> email saying that it's useless to contribute and that ffmpeg is so
> much better, so they should be contributing to it instead.
> I think the exact opposite, since ffmpeg merges everything from Libav,
> there is little point in sending patches to ffmpeg in the first place,
> but I also think that everyone is free to do whatever they want, so
> I'm totally fine with that.

See above. Contributors don't want to merge tons of FFmpeg stuff just
to be able to send a patch to some "other" FFmpeg-like project.

Keep in mind that not everyone targets his applications to run on Linux
distros. So they will just pick one project and stick with it. And if
that is FFmpeg (which generally has slightly more features and slightly
fewer bugs), then they really have no reason to care about Libav at
all. IMO it's really _you_ as Libav developer who is in the worse
situation here.

And last time I posted a patch to Libav, MiNi made a tons of
corrections to the patch on the FFmpeg side. I backported these
patches, but they _still_ haven't been pushed by Libav.

Honestly, this situation is a bit baffling and insane.

> > Even more ironic, iam sure most libav developers would be happier had
> > the fork never happened but it did and now people seem stuck in that
> > split ...
> 
> Libav developers are quite happy thanks, but would probably do better
> without the insults, trashing and bad PR received here for no
> particular reason. Ironically I am sure most ffmpeg developers would
> be happier if the continuous merging would not continue.

I'm sure there's lots of bad blood on both sides and maybe even from
3rd parties. The fucked up current situation puts stress on everyone.
Nevertheless I would suggest to at least try to work towards a
solution, or at least not to work _against_ possible improvements that
could be made.

The current situation as it is causes lots of unnecessary and
frustrating work for (almost) everyone.

Personally, I would also prefer if MiNi wasn't caused up in merging
code 24/7 (I'm sure that must be boring and he has better to do),
instead of developing stuff.

> Incidentally I think that everyone would have been happier if you
> respected the rules and stepped down as project leader when the
> majority of developers voted against you back then. That would have
> most likely prevented the fork in the first place...

Maybe or maybe not, but that's in the past. If you play the blame game,
nothing ever will change.

Also, likewise I could say: what if Libav had merged all FFmpeg
changes? Maybe then you could just send a patch with both project
mailing lists as recipients, and mistakes in the patches would be
caught early by both sides.

But we can't change the past, so let's try to find a solution in the
present?

> Anyway, as I said in my previous email this is way off topic, and the
> discussion is not leading anywhere, so I recommend continuing off list
> if anyone wants to.
> Cheers,



More information about the ffmpeg-devel mailing list