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