[FFmpeg-devel] [PATCH 0/3] Include headers for cuvid

[Philip Langdale]

On Wed, 21 Sep 2016 15:09:36 +1000
Matt Oliver <protogonoi at gmail.com> wrote:

> On 21 September 2016 at 14:38, Philip Langdale <philipl at overt.org>
> wrote:
> 
> > The cuvid header situation is a mess - the only feature-complete
> > headers are
> > in the Video SDK and not in the cuda header collection. The headers
> > in the Video SDK are MIT licenced, and so we can bundle them like
> > we do the nvenc header.
> >
> > Once bundled, we do need to tweak them to remove the use of a
> > dynlink system that's specific to the Video SDK samples, which we
> > don't need and don't really want.
> >  
> 
> Does using the MIT headers instead effect the current licensing
> constraints on cuvid (as its nonfree at present). I was just
> wondering if keeping in the dynlink_cuda stuff could be used to
> remove the cuda compile dependency and actually allow cuvid compiles
> to be distributed. _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Unfortunately not. the dynlink_cuda.h is not MIT licenced so you still
end up with that as an external dependency.

For our nvenc usage, the cuda function prototypes are redeclared to
avoid a dependency on cuda.h. I guess you could do the same for cuvid,
but the set of functions is much more extensive.

On the library side, the story is fine as libcuda and libnvcuvid are
distributed with the driver like libnvidia-encoder which we decided
was acceptable to link/dlopen.

I feel I'm missing something in the overall picture - how did we end up
in a situation where we decided that a proprietary library was an
acceptable dependency but the header for that library is not. For all I
know, maybe we're actually ok with using cuda.h at build time and still
being gpl compliant.

In general I've not read any discussion of the cuda runtime licence
being GPL incompatible. IANAL etc.

--phil