On 31/10/17 16:34, Timo Rothenpieler wrote: > Removing the nvenc/cuvid headers from the tree would imply the following > procedure for anyone wanting to build ffmpeg with nvenc/cuvid: > > Register with nvidia to get access to their Video SDK Downloads. > Extract the headers from their massive SDK. > Patch them so that ffmpeg can make use of them. The vanilla headers are not > useful for ffmpeg, as they are not in a format that can be easily included. > All the headers in the tree are slightly modified to avoid some > type-collision, extend compatibility(for example with Cygwin) and for the > dynamic loading we do. > > Putting that state of headers into an external repository that someone > maintains seems like a giant and confusing mess for every user and > distributor. And I don't see any benefit in doing that. > > The headers are MIT licensed, so there is no license issue to be found here. > They don't cause any issues on any platform where they are used by default. > > I also do not see any problem with including the new single-header AMD > encoder, it makes everyone's life easier and avoid confusing proxy libraries. > > We're not bundling entire 3rd party libs in-tree here, just API headers for > system/driver APIs.
What exactly would the policy be, then? "External headers for a system/driver API may be included in tree if it makes building with support for this feature easier for users" would cover pretty much everything. I'm definitely against a free-for-all where libmfx, V4L2, etc. all get included. - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
