[FFmpeg-devel] Project orientation

Anton Khirnov anton at khirnov.net
Sun Jul 5 14:41:59 EEST 2020


Quoting Tomas Härdin (2020-07-05 13:19:25)
> 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.

I have been thinking about something like a staging branch. Or multiple
such "experimental" branches in the main repository, which would still
be "official" in some sense, even though they wouldn't be the master
one.

There obviously seems to be a conflict of visions between people who
want ffmpeg to be a stable consistent coherent tool for our downstreams
and those who want to play with experimental concepts, cute hacks and
fringe features. I would count myself among the former, but the latter
is also a valid worldview and should not be disregarded. I would like to
hope some kind of a compromise can be found.

Will write a more complete reply to OP later.

-- 
Anton Khirnov


More information about the ffmpeg-devel mailing list