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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
