On Sun, May 12, 2019 at 12:07:42PM -0700, Tim Jones wrote: > On May 12, 2019, at 11:54 AM, Nicolas George <[email protected]> wrote: > > > > Tim Jones (12019-05-12): > > > >> --disable-all-proprietary/--enable-all-proprietary > > > > As for this one, on the other hand, there will be opposition: we do not > > want encourage users to use proprietary software. In fact, there is > > currently a discussion to refuse including new proprietary components, > > and possibly getting rid of the ones we included without thinking. > > I don't want to start a thread war here, but isn't the purpose of any > toolchain to allow for the support of a given task? If there isn't a FOSS > option and an easily obtained proprietary solution exists, why block it? > > This is one of the things I hear from new Linux users when running into the > FOSS vs. proprietary brick walls - they just want a platform that works. The > FUD that is continuously promoted concerning adding non-FOSS components - > Nvidia drivers, ATTO drivers, HighPoint drivers, custom audio device drivers > - has caused a number of potentially large Linux opportunities to move to > Windows. > > I've long been a proponent of FOSS where it is apropos, but I also understand > Heinlein's TNSTAAFL :) .
Well, which is a fairly good argument to enable proprietary components only in specific cases. There is a cost in doing the auto-detection, there is a cost in maintaining it, there is a cost in supporting it when it breaks - especially when it completely breaks FFmpeg even for users who have no use for it (this can easily happen with libraries that do not properly namespace symbols and hide the non-namespaced ones for example). But as always it is a cost vs. benefit question. And I'd also add that it's not really specific to proprietary, it applies to all external dependencies, most are not enabled by default even when they are FOSS. Unfortunately we don't really have the data to say which features are used often, which makes the whole cost vs. benefit consideration a bit hard. _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
