On 21 September 2016 at 15:28, Philip Langdale <phil...@overt.org> wrote:
> On Wed, 21 Sep 2016 15:09:36 +1000 > Matt Oliver <protogo...@gmail.com> wrote: > > > On 21 September 2016 at 14:38, Philip Langdale <phil...@overt.org> > > wrote: > > > > > The cuvid header situation is a mess - the only feature-complete > > > headers are > > > in the Video SDK and not in the cuda header collection. The headers > > > in the Video SDK are MIT licenced, and so we can bundle them like > > > we do the nvenc header. > > > > > > Once bundled, we do need to tweak them to remove the use of a > > > dynlink system that's specific to the Video SDK samples, which we > > > don't need and don't really want. > > > > > > > Does using the MIT headers instead effect the current licensing > > constraints on cuvid (as its nonfree at present). I was just > > wondering if keeping in the dynlink_cuda stuff could be used to > > remove the cuda compile dependency and actually allow cuvid compiles > > to be distributed. _______________________________________________ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > Unfortunately not. the dynlink_cuda.h is not MIT licenced so you still > end up with that as an external dependency. > > For our nvenc usage, the cuda function prototypes are redeclared to > avoid a dependency on cuda.h. I guess you could do the same for cuvid, > but the set of functions is much more extensive. > > On the library side, the story is fine as libcuda and libnvcuvid are > distributed with the driver like libnvidia-encoder which we decided > was acceptable to link/dlopen. > > I feel I'm missing something in the overall picture - how did we end up > in a situation where we decided that a proprietary library was an > acceptable dependency but the header for that library is not. For all I > know, maybe we're actually ok with using cuda.h at build time and still > being gpl compliant. > > In general I've not read any discussion of the cuda runtime licence > being GPL incompatible. IANAL etc. > > --phil > Well its just that both cuvid and cuda are both currently flagged as nonfree in FFmpeg which limits there availability. So I was just wondering what needed to be done to make them gpl compatible as I would like to see cuvid be more available. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
