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

Hendrik Leppkes h.leppkes at gmail.com
Sat Dec 12 11:35:27 CET 2015

On Sat, Dec 12, 2015 at 11:25 AM, Andreas Cadhalpun
<andreas.cadhalpun at googlemail.com> wrote:
> On 12.12.2015 10:50, Hendrik Leppkes wrote:
>> On Sat, Dec 12, 2015 at 10:39 AM, Andreas Cadhalpun
>> <andreas.cadhalpun at googlemail.com> wrote:
>>> On 12.12.2015 01:46, Philip Langdale wrote:
>>>> On 2015-12-12 00:03, Andreas Cadhalpun wrote:
>>>>> On 11.12.2015 09:41, Carl Eugen Hoyos wrote:
>>>>>> 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.
>>> Interesting...
>>>> I'm, instead, going to
>>>> ask why we're having this conversation about nvenc, when the qsx/mfx
>>>> situation is exactly the same.
>>> We have this conversation, because someone sent a patch to enable it
>>> by default, together with including the header and removing the
>>> 'die_license_disabled nonfree nvenc' line.
>>>> 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.
>>> Since this requires the mfx wrapper to link, it is not enabled by
>>> default. As the license situation seems similar, it might be a good idea
>>> to add a 'die_license_disabled nonfree libmfx' line. But these don't have
>>> any effect on the legal situation anyway, they are just a help
>>> for our users.
>>>>>> 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.
>>> No, it's not, because the LGPL and GPL are very similar in terms of the
>>> requirements about distributing object code of (L)GPL-ed source code.
>>>> Combining ffmpeg with proprietary libraries is covered under section 6 and
>>>> section 7,
>>> These sections only cover "work that uses the Library" (defined in section 5),
>>> not the Library itself.
>>>> 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.
>>> No, see section 4:
>>> "You may copy and distribute the Library (or a portion or derivative of it,
>>> under Section 2) in object code or executable form under the terms of Sections
>>> 1 and 2 above provided that you accompany it with the complete corresponding
>>> machine-readable source code"
>>>> Note that I actually don't believe with have a GPL problem here,
>>> Why?
>>>> 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.
>>> I don't agree with that interpretation, see above explanation.
>> We should just add an exception into the license to explicitly allow
>> using it with the NVIDIA CUDA library and be done with this debate for
>> ever.
> That would be an option.
>> You know that Open-Source has failed when the project itself is
>> arguing days and days for including a feature on license reasons that
>> any closed-source app would just write, enable and offer to its users
>> without a second thought.
> Please try to take a step back.
> The "nvenc" feature is already included in FFmpeg, just not enabled by
> default.

And not enabled on any distribution, hence 99% of all users don't see
it or get to use it.

- Hendrik

More information about the ffmpeg-devel mailing list