> On 5/12/2017 5:21 AM, Timo Rothenpieler wrote: > Am 12.05.2017 um 15:34 schrieb James Almer: > > On 5/12/2017 5:21 AM, Timo Rothenpieler wrote: > >> Am 12.05.2017 um 07:32 schrieb Yogender Gupta: > >>>>> + cuda_sdk > >>>>> libnpp > >>> > >>> IMO, Libnpp is part of the CUDA SDK, and we can remove all the libnpp > >>> related changes and just replace it by cuda-sdk in the configure/make > >>> files. > >> > >> True, but I'm not sure if an existing config parameter can be that > >> easily removed without breaking a bunch of existing build scripts. > > > > You can keep the option marked as deprecated for a while, while removing > > all the relevant internals and making it an alias for cuda_sdk. > > Thinking about it, I'd rather keep libnpp separate, as --enable-cuda-sdk > still results in an ffmpeg binary that only depends on stuff the > nvidia-driver ships with, while for a build with libnpp it depends on > some libs that only come with the CUDA SDK.
Hi, in the above context I'm wondering about whether it is mandatory to treat the "cuda_sdk" option as a non-free option? In case of libnpp it's obviously required to statically link to proprietary Nvidia code code for which there's not public source code available. But for yadif_cuda and scale_cuda it's just about dynamic linking to a system component (driver), which seems to be allowed by the GPL or GPLv3 at least. Are my assumptions correct? If yes, could we move 'cuda_sdk' from the HWACCEL_LIBRARY_NONFREE_LIST to the HWACCEL_LIBRARY_LIST in order to allow using the cuda filters even with GPL builds? Thanks, softworkz _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
