On Thu, Apr 26, 2018 at 4:12 PM, Daniel Oberhoff <danieloberh...@googlemail.com> wrote: > >> On 26. Apr 2018, at 14:08, Hendrik Leppkes <h.lepp...@gmail.com> wrote: >> >> On Thu, Apr 26, 2018 at 2:06 PM, Daniel Oberhoff >> <danieloberh...@googlemail.com> wrote: >>> Hello, >>> >>> I just started programming to directly use the cuda decoded frames on the >>> gpu (working off master). Would it be possible to publicly expose the >>> loaded cuda functions? This way I can inherit the possibility to build with >>> cuda support but run in absence of cuda on the target. Currently these are >>> hidden from the public interface. >>> >> >> This doesn't belong into the API, so thats not going to happen, but >> the CUDA loader we use is public and you can just use it to do the >> same thing: >> http://git.videolan.org/?p=ffmpeg/nv-codec-headers.git;a=summary > > Hmm, what is the rationale? You do expose the cuda context, so you do expose > the fact that you use the cuda library. Also this will only work if i load > the same library (there may be multiple on one system). I guess using > nv-codec-headers that would be given, but then I am exploiting an > implementation detail. It seems so much cleaner to just expose the functions > in the AVCUDADeviceContext... >
You could make this argument for every library. We expose the data, how we access CUDA is an implementation detail, it might as well be linked in instead of loaded at runtime and the user should not care. We're not going to include the CUDA API/ABI in our public headers. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
