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

Matt Oliver protogonoi at gmail.com
Wed Sep 21 11:02:47 EEST 2016


On 21 September 2016 at 15:28, Philip Langdale <philipl at overt.org> wrote:

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

Well its just that both cuvid and cuda are both currently flagged as
nonfree in FFmpeg which limits there availability. So I was just wondering
what needed to be done to make them gpl compatible as I would like to see
cuvid be more available.


More information about the ffmpeg-devel mailing list