[FFmpeg-devel] To be or not to be working with libav (was: [PATCHv3] On2 VP7 decoder)

[wm4]

On Sun, 6 Apr 2014 20:41:03 +0200
Vittorio Giovara <vittorio.giovara at gmail.com> wrote:

> On Sunday, April 6, 2014, Nicolas George <george at nsup.org> wrote:
> 
> > Le septidi 17 germinal, an CCXXII, Vittorio Giovara a écrit :
> > > The easiest solution would be to stop the daily merge and let the two
> > > projects live on their own
> >
> > You keep suggesting that: what good do you think that would achieve?
> 
> 
> Uhm, competition?
> Foss projects foster on innovative ways of tackling problems, and that
> pushes developers to improve their code. When a project keeps pulling
> features from another and adding on top of it, it stifles competition and
> demotivates developers, with the end result that *less* open source code is
> written.

In terms of competition, FFmpeg not merging from Libav anymore would of
course be better for Libav. But surely you understand that FFmpeg can
not do this.

> 
> Also Libav code is so ill received most of the times that I seriously can't
> figure out why this is still happening. The two projects have completely
> separate design approach and dev model so it's really difficult to
> understand, in my opinion

I don't always understand it either. But in general, full merges are
seen as necessary evil within FFmpeg. The loss of control probably
contributes to the fact that Libav changes are seen much more
critically as opposed to if they had been discussed and reviewed by
FFmpeg developers too.

> When a new feature arrives in avconv, what happens if it is not merged into
> > ffmpeg? Shall it be left out? Or re-implemented independently?
> 
> 
> Being left out until someone actually needs it is a way. Otherwise you just
> get complaints and unnecessary features that might collide with your design
> goals. See for example the mv visualization deprecation and undeprecation
> of a few days ago or many others I could quote.
> 
> 
> > The first one is bad for the users, the second one is a waste of
> > developers'
> > time.
> 
> 
> This whole downstream situation is bad for users and developers. This is
> why I'm insisting to get past each other differences and see if there is
> room for collaboration, rather than one-way pulling.

What are you suggesting? What kind of collaboration? By the way, it
would be much easier if Libav merged everything FFmpeg does (and
routinely does so), because if the code is the same, there is no
problem in the first place.

I envision the following "double filtering" development process:

   FFmpeg -> cherrypick by Libav dev -> Libav -> merge -> FFmpeg -> repeat

This way the code will be incrementally improved by funneling a patch
through review and merge processes a few times. FFmpeg git and Libav git
would remain the same, and the two projects merely enforce a very weird
development/review process.