On Thu, May 26, 2016 at 8:12 PM, Andrey Turkin <andrey.tur...@gmail.com> wrote: > > Enabling CUDA support adds some extremely useful features but it also > adds hard runtime dependency on NVidia driver. This commit removes that > dependency; driver library would be loaded when required. > This allows to use same CUDA-enabled FFMpeg build on machines with and > without NVidia cards. > CUDA toolkit is still needed at build time. scale_npp filter still adds > runtime dependency on libnppc and libnppi (which is fine since these > libraries have to be redistributed with FFMpeg anyway, and they load > CUDA internally on demand as well). > --- > Same patch was sent to libav ML > > configure | 9 ++-- > libavcodec/nvenc.c | 24 ++++++---- > libavfilter/vf_hwupload_cuda.c | 22 ++++++--- > libavfilter/vf_scale_npp.c | 12 ++++- > libavutil/Makefile | 4 +- > libavutil/cuda_api.c | 102 > +++++++++++++++++++++++++++++++++++++++++ > libavutil/cuda_api.h | 53 +++++++++++++++++++++ > libavutil/hwcontext_cuda.c | 36 +++++++++------ > 8 files changed, 227 insertions(+), 35 deletions(-) > create mode 100644 libavutil/cuda_api.c > create mode 100644 libavutil/cuda_api.h >
I really don't like adding factually public API/ABI to avutil for this (avpriv is still part of the public ABI), we've been over this with whole topic with QSV and the same conclusion applies here. We have support for a variety of external libraries, which require an external SDK to build and impose redistribution and runtime restrictions. I don't see a convincing argument why CUDA should be special, and litter avutil API/ABI with cuda-specifics to achieve that. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel