[FFmpeg-devel] Project orientation

[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.

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.

>
> 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.

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.

Regards,
Marton