[FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header

Matt Oliver protogonoi at gmail.com
Thu Dec 10 17:42:43 CET 2015


>
> > >>> What is a system library depends on the system.
> > >>> For example, Debian (main) does not even include libcuda or
> > >>> libnvidia-encode, so they certainly cannot be system libraries there.
> > >>
>

Im not sure that Debian not including libcuda is a valid argument for it
not being a system library as thats just one OS. To me thats the same as
saying that win32 stuff is not part of a system library because Debian
doesnt have it (for obvious reasons). So I dont believe that just because
some systems dont have it doesnt stop it from being a system library. And
if a system doesnt have the required propriety libs then they wont be
loaded at runtime and therefore no proprietary code is ever used at all.

> > The ffmpeg binary that results from including nvEncodeAPI.h is GPL
> > > compatible because nvEncodeAPI.h is MIT licenced.
> >
> > I'm not sure it's that easy. If that were correct, it would become
> > GPL-compatible to distribute a GPL-licensed program linked with a
> > proprietary library by simply inserting a MIT licensed header in the
> middle.
>

In this case thats not what is being said as we are not actually linking
against anything. As if we did link against a propriety lib then you would
be correct and this would brake GPL but that is not the case as the nvenc
binaries are only accessed at runtime. All were doing here is including a
single header file.

> > The only time the GPL ffmpeg and the proprietary licenced nvidia
> libraries
> > > are combined is on the end user system so no distribution occurs, so
> the
> > > GPL language doesn't apply at that stage.
> >
> > However, the object code compiled from nvenc.c would get distributed as
> part of
> > the ffmpeg binaries, which is governed by the GPL.
>

The object code from nvenc.c is written using LGPL and just includes
declarations (no actual code definitions) from a MIT header file which to
me suggests that the part of ffmpeg that would be distributed is still GPL
compliant. At no point during the entire compilation and linking stage is
any proprietary component touched so I dont see how this brakes anything.
So sorry for being verbose (and potential just stating the obvious) but the
only argument here is whether we can consider the libs accessed at runtime
as system libs or not.

To use windows as a further example all the actual binary code required for
nvenc to work is part of the graphics drivers. So the only time anything
not GPL compliant is ever used is when the dll's are loaded at runtime from
the driver. This definitely puts it in the category of a system component
in my mind. If drivers are not considered system libs then we have far more
serious problems than nvenc ;)

Admittedly, we are solving someone else's problem, but the header is
> buried inside the SDK download which is hidden behind a click-through on
> nvidia's web page. So it's not made available in a way that is readily
> consumable by an end user or by a distribution vendor.
>
> With the new licencing, a distro vendor *could* take the header and package
> it up themselves, but that's the sort of them that's exceptionally hard to
> convince them to do.
>
> And in the case of windows (where nvenc works too), there is no distro
> vendor
> and nvidia certainly won't make the header more accessible than it already
> is.


I agree with Philip here as the nvEncodeApi header is not part of a cuda
sdk install and requires a separate download. One which is not as easily
accessible and one that requires a good 90MB download just to use 1 header
file. Since the header is all that is needed and it is not part of a
standard sdk then I think the inclusion of avisynths headers already sets a
precedent to also include this one. Including it also allows ffmpeg to
ensure that the correct newer MIT licensed version is the only one being
used. Of course this does put the burden on ffmpeg to ensure that the
header is kept up to date but as long as someone does that then I support
its inclusion (I dont see an issue with keeping it up to date as anyone
adding new features will inherently update it and any breakage would be a
result of the interfaces changing which would brake ffmpeg anyway).

So the updated patch looks good to me.


More information about the ffmpeg-devel mailing list