[FFmpeg-devel] Project orientation

[Tomas Härdin]

sön 2020-07-05 klockan 14:28 +0200 skrev Marton Balint:
> 
> On Sun, 5 Jul 2020, Tomas Härdin wrote:
> 
> > 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.
> 
> That is the point. Baptise is focusing on other things, and the code he 
> used to do rots in an external repository. I guess most of the features he 
> implemented crept back to ffmpeg (I did the backporting of some features 
> myself), but still, it was duplicate work.

It's not duplicate work if the work wouldn't have happened at all in
the first place.

We could probably work toward merging more features from FFmbc into
FFmpeg since presumably Baptiste doesn't depend on the license trolling
aspect of the former any more. I could probably do it if Baptiste would
be willing to dual license them and we could find a bit of funding for
it.

> Forks are good, if you are submitting the code back to master. If not, 
> then forks are not so good because they often dont't live on alone and you 
> lose the features in it.

Here is where scope/feature creep becomes a problem. Features aren't
free. Every feature is a liability and needs to be maintained. I for
one don't have infinite time to spend. This is why I focus mostly on
MXF.

> > 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.
> 
> x262 is another example of a fork, where the fork alone was not 
> popular/interesting enough to live on. If it were merged to x264, I am 
> fairly certain it would not be experimental anymore, and we'd have an 
> MPEG2 encoder which would scale much better to multiple cores than what we 
> have now in ffmpeg.
> 
> So having something merged and maintained in ffmpeg has the benefit that 
> more people have the ability to test the code and to develop it. Also it 
> is more likely for the project to get developers if their code live in the 
> core ffmpeg respository. I also don't see that maitenance burden to be so 
> huge. And usefulness is also questionable. I think it is safe to say that 
> having AMQP/ZMQ protocol support is much more useful then Lego Racers 
> demuxer... (and I quite liked Lego Racers!!!).
> 
> So my opinion would be to be inclusive when merging stuff. I am not saying 
> everything has to be merged, I rejected not very long ago the NIT table 
> parsing or the EPG "data decoder", these were really out of scope and more 
> importantly out of the current capabilites of the framework. And if 
> distros are worried about dependencies, they can always make two packages, 
> a normal and a full.

Decent enough points. I just prefer being a bit more conservative with
what gets in, due to the maintainance burden.

> And I'd also like to point to the linux kernel as an example of a 
> monolitic code repository which seems to work quite well.

Kernel development being quite well-delegated may contribute to this.
Perhaps FFmpeg should move more in such a direction? Might be
interesting.

/Tomas