[FFmpeg-devel] Project orientation

Tomas Härdin tjoppen at acc.umu.se
Sun Jul 5 14:19:25 EEST 2020


sön 2020-07-05 klockan 12:42 +0200 skrev Marton Balint:
> 
> On Sun, 5 Jul 2020, Tomas Härdin wrote:
> 
> > sön 2020-07-05 klockan 00:10 +0200 skrev Jean-Baptiste Kempf:
> > > On Sat, Jul 4, 2020, at 23:51, Michael Niedermayer wrote:
> > > > On Sat, Jul 04, 2020 at 11:25:31PM +0200, Jean-Baptiste Kempf
> > > > wrote:
> > > > [...]
> > > > > At some point, the project needs to decide what is in and what is
> > > > > out, and since FFmpeg has numerous APIs, people can plug them
> > > > > externally. It's not a problem to say "No" to a feature,
> > > > > especially when, the number of people using that feature is under
> > > > > 0,01% of FFmpeg users, and when people can build that externally
> > > > > anyway.
> > > > 
> > > > what we need is not to say "no" but to say 
> > > > "use this API, implement the module in your own repository, and
> > > > register your module there"
> > > 
> > > Once again, Michael, we agree, on this topic.
> > > 
> > > No, means "not in the ffmpeg repo" does not mean "no, this is not
> > > useful".
> > 
> > I'd like to express a general agreement with this point. The project
> > has experienced quite a lot of scope creep lately. We don't have to
> > accommodate everyone, especially with the finite number of developers
> > available.
> > 
> > We can encourage people to maintain their own forks of FFmpeg, see for
> > example FFmbc.
> 
> And see how dead that project is. Or ffserver. Or x262.

That may be because Baptiste is focusing on other things. The code is
still there. It still compiles.

Would you want something experimental like x262 to be part of the
FFmpeg codebase, for us to have to maintain forever? If you don't limit
scope then that is what would happen.

/Tomas



More information about the ffmpeg-devel mailing list