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

[Jean-Baptiste Kempf]

On 10 Dec, Philip Langdale wrote :
> >Are we really talking about including a huge 3rd party header because
> >distros are so lazy? What's next, do we add Windows headers to the
> >FFmpeg tree, because MinGW lags severely behind the newest definitions
> >like HEVC DXVA support?
> 
> 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.

Sorry, but that's true about most headers for Windows, for example, or
for the Android SDK/NDK, or for the iOS SDK.

If someone is able to compile FFmpeg, he's able to get access to a
header.

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

How is that an argument? When have the distributions being lazy on such
a thing?
On the opposite, I'm quite sure most Linux distributions do not want forking
of other libraries/headers/code into other applications/libraries.
See the current debates on Debian and Fedora and CSS/JS code.

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

The Windows SDK is not very accessible either.

> If the goal is to make the feature as available as possible to as many users
> as possible, then this is the way to do it.

I believed the goal was to make the correct thing, not make one feature
as available as possible.
Else, why are you not forking libmfx into the tree then? or crystalhd
headers (pure dlopening on Windows)?

With my kindest regards,

-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device