On 31/10/17 23:52, Carl Eugen Hoyos wrote: > 2017-10-31 17:52 GMT+01:00 Mark Thompson <s...@jkqxz.net>: >> On 31/10/17 16:34, Timo Rothenpieler wrote: > >>> 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. > > Could you elaborate? I apparently miss something. > Why would anybody want to put a libmfx or v4l2 header into the > FFmpeg codebase?
For the same reason that they might add the AMD one - it would always be present so that no external dependencies are required for building. The argument for AMD seems to be primarily "Nvidia has this so we should too" rather than anything to do with actual requirements (like libmfx or V4L2, it is easily available without bizarre hoops to jump through). This is why I'm concerned that we are facilitating anti-open behaviour from Nvidia by making it easier to use the closed software than more open alternatives. - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
