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

Hendrik Leppkes h.leppkes at gmail.com
Sat Dec 12 10:50:23 CET 2015

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

- Hendrik

More information about the ffmpeg-devel mailing list