[FFmpeg-devel] FW: Requirements for compiling with CUDA_SDK option enabled

Soft Works softworkz at hotmail.com
Sun Feb 17 08:24:05 EET 2019

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


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?


More information about the ffmpeg-devel mailing list