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

[Philip Langdale]

On 2015-12-12 00:03, Andreas Cadhalpun wrote:
> On 11.12.2015 09:41, Carl Eugen Hoyos wrote:
>> On Friday 11 December 2015 12:16:48 am Andreas Cadhalpun wrote:
>>> Well, the problem is that the answer may depend on the system.
>> 
>> If Nvidia offers Graphics Driver for download on its ftp server
>> for multiple operating systems, they are either system libraries
>> or not, I really don't see how this can depend on the operating
>> system.
> 
> For reference, here is the system library exception from LGPL-2.1 [1]:
> "However, as a special exception, the materials to be distributed need
> not include anything that is normally distributed (in either source or
> binary form) with the major components (compiler, kernel, and so on)
> of the operating system on which the executable runs, unless that
> component itself accompanies the executable."
> 
> So in general, there can be operating systems were Nvidia's blobs
> are normally distributed together with e.g. the kernel and others
> were this is not the case.
> 
>> I don't see any reason why the fact that these drivers
>> have to (or can) be downloaded by the user does not make them
>> system libraries.
> 
> When running ffmpeg on Debian (main), where these Nvidia blobs
> are not present and not needed (because nouveau is used as driver),
> no component of the operating system, major or not,
> has been distributed with Nvidia's blobs, so the system library
> exception does not apply.
> 
> I'm not sure about the situation for Windows.
> 
>> My point is that so far several people have said that if nvenc
>> is a system library there is no issue (and I fully agree). I
>> didn't see a mail (and even less a patch with a commit message
>> that says so) that claims nvenc is a system library (only that
>> it "should" be one).
> 
> So let's ask: Is someone here who claims that nvenc is a system
> library and can explain why?

I'm not going to claim it's a system library. I'm, instead, going to
ask why we're having this conversation about nvenc, when the qsx/mfx
situation is exactly the same. The functionality is provided by a
proprietary set of modules that are part of the intel driver on windows
and a separate (almost undiscoverable) download on linux (actually,
that's worse than nvenc where the functionality is shipped with the
driver in both cases). The only structural difference is that ffmpeg
links against a wrapper library for mfx and dlopens in the nvenc
case, but because of your following statement, that cannot make any
difference.

>> I am glad we agree that there is no difference (license-wise) if
>> a library is linked statically, dynamically or via dynamic
>> loading;-)
> 
> There is that, at least. ;-)

Oh, and do you know what's funny - I just realised that the primary 
ffmpeg
code base is LGPL and not GPL, so this whole conversation is slighlty
pointless.

Combining ffmpeg with proprietary libraries is covered under section 6 
and
section 7, so even if building the nvenc codec is considered to combine
ffmpeg with nvenc in this sense, it would be acceptable. The key 
requirement
is that the LGPL covered parts can be rebuilt and modified as desired, 
and
that is certainly true.

These sections are generally thought of as enabling a larger proprietary
program to pull in an LGPL library, but the language is symmetric.

Note that I actually don't believe with have a GPL problem here, but as 
a
step forward, if we can all agree that the nvenc codec is a valid part 
of
an lgpl build of ffmpeg, that's a step forward.

--phil