On 26/10/17 19:03, Mironov, Mikhail wrote: >> -----Original Message----- >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf >> Of wm4 >> Sent: September 29, 2017 12:57 PM >> To: ffmpeg-devel@ffmpeg.org >> Subject: Re: [FFmpeg-devel] Added HW accelerated H.264 and HEVC >> encoding for AMD GPUs based on AMF SDK >> >> On Fri, 29 Sep 2017 15:04:00 +0000 >> "Mironov, Mikhail" <mikhail.miro...@amd.com> wrote: >> >>> I would like to understand better the nature of the concern. The license is >> MIT. The paragraph in question is a notice, not limiting the usage of the >> SDK. >>> I can definitely reduce number of headers. I can merge all necessary >> interfaces into one header, though maintenance will take more resources. >> Which way would you prefer? >> >> Ideally, these headers would just be easily installable by whoever wants to >> build FFmpeg with AMF. This is how it works normally for external libraries. >> >> I don't even understand why we added those NVIDIA and avisynth headers >> (the other things in compat are for basic OS compatibility, so not >> comparable). For NVIDIA in particular it's probably because installing their >> SDK is a major PITA and there was something about license issues. >> Maybe someone else could chime in why this was done? >> >> At least for nvenc there was an explanation given in the commit message: >> >> As Nvidia has put the most recent Video Codec SDK behind a double >> registration wall, of which one needs manual approval of a lenghty >> application, bundling this header saves everyone trying to use NVENC >> from that headache. >> >> The header is still MIT licensed and thus fine to bundle with ffmpeg. >> >> Not bundling this header would get ffmpeg stuck at SDK v6, which is >> still freely available, holding back future development of the NVENC >> encoder. >> >> So basically, NVIDIA being... let's say, "not nice". I don't think this will >> be a >> problem with AMD. >> >> Again, we generally don't add headers for external libraries in-tree. > I understand your concerns but keeping AMF headers outside of FFmpeg tree > would put Nvidia into unfair advantage. And this will happen only because > they obscured access to their SDK. I plan to resubmit the patch with a single > header file with reduced AMF API. The license will be pure MIT. Mikhail
Why would you even want this? It just makes things more inconvenient, since the headers end up having to follow latest version and therefore cause problems with the older versions which many users are running. If AMD can provide headers matching the implementation on a given system (like all normal libraries do) then that's just better for everyone. More generally, I don't think it is particularly sensible to be importing external headers to the ffmpeg tree. IMO the Nvidia situation could have been done better - if Nvidia themselves are incapable of providing usable headers, some user could easily have made a repository providing suitable versioning which then all users could adopt rather than each project reinventing the wheel separately. (This was done for Intel libmfx - <https://github.com/lu-zero/mfx_dispatch>. That was mainly a packaging/linking issue rather than a header one, but I think the same principle applies.) So: * If AMD provides usable headers directly with their packages then we should just use them. * If the AMD package is not usable for whatever reason (stupid licensing or whatever), then AMD could create an official repository holding just the build-necessary components in a simple form and we would use that. * Otherwise, since you say the headers are MIT, some individual (such as yourself) could make that same repository as an individual independent of AMD. (I do think Nvidia should do this too. I'm not involved with Nvidia development at all, though.) Thanks, - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
