Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 12/10/15, Philip Langdale wrote: > On 2015-12-09 21:34, wm4 wrote: >> On Mon, 7 Dec 2015 19:34:20 +0100 >> Timo Rothenpieler wrote: >> >>> > I don't remember if this was discussed when avisynth and other headers >>> > where included, but what's the advantage of directly including the >>> > header and burden the FFmpeg sources, rather than asking the user to >>> > download them in case of need? >>> >>> The nvenc sdk isn't exactly a common thing that distributions provide. >>> As distributions can now easily ship ffmpeg with nvenc support, this >>> propably helps users who now no longer need to build ffmpeg themselves >>> for nvenc support. >> >> So why would distros build with nvenc support, if they can't even do a >> simple thing like installing a single header file? >> >> 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? >> >> We could just provide a download link for the nvenc header somewhere if >> the problem is finding the header. > > 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. I have had some success scripting its download in the past, FWIW :) Cheers! -roger- echo "installing nvenc [nvidia gpu assisted encoder]" curl http://developer.download.nvidia.com/assets/cuda/files/nvidia_video_sdk_6.0.1.zip -O -L unzip nvidia_video_sdk_6.0.1.zip cp nvidia_video_sdk_6.0.1/Samples/common/inc/* $mingw_w64_x86_64_prefix/include ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 10.12.2015 20:37, Nicolas George wrote: > Le decadi 20 frimaire, an CCXXIV, Andreas Cadhalpun a écrit : >> Using the header, one could create a dummy libfoo.so containing only >> stub functions. > > Exactly. > >> I don't think the FSF would agree [1]. > > They do not make the law. Neither do you or I. > Claiming that the GPL enforces more than it can is obviously their game. Ultimately, the only definitive answer can come from a court decision, which will hopefully not be needed here. >> The GPL does not require that programs can run, only that distributors >> provide the source code of everything that is needed to run the program, >> except system libraries. >> >> So you can distribute e.g. a GPL binary linking with libfoo.so, without >> distributing libfoo.so, as long as you distribute the source code >> of libfoo.so. >> However, claiming that libfoo.so is not required to run the binary >> would be bizarre. > > Once again, exactly. I agree that having the program not work at all would > probably not be sustainable. But for an optional feature (a codec, for > example), having a GPL-compatible stub libfoo.so that just prints "feature > not available" is perfectly legal. One could argue endlessly about where to draw the line... On the other hand I think we agreed to not enable nvenc by default, so lets just do it that way. That leaves the question of whether or not to include the header, but I have no strong opinion on that. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
Le decadi 20 frimaire, an CCXXIV, Andreas Cadhalpun a écrit : > Using the header, one could create a dummy libfoo.so containing only > stub functions. Exactly. > I don't think the FSF would agree [1]. They do not make the law. Claiming that the GPL enforces more than it can is obviously their game. > The GPL does not require that programs can run, only that distributors > provide the source code of everything that is needed to run the program, > except system libraries. > > So you can distribute e.g. a GPL binary linking with libfoo.so, without > distributing libfoo.so, as long as you distribute the source code > of libfoo.so. > However, claiming that libfoo.so is not required to run the binary > would be bizarre. Once again, exactly. I agree that having the program not work at all would probably not be sustainable. But for an optional feature (a codec, for example), having a GPL-compatible stub libfoo.so that just prints "feature not available" is perfectly legal. And then, you just have to propose the customers to download, on their own responsibility, a proprietary libfoo.so. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 10.12.2015 19:48, Matt Oliver wrote: > On 11 December 2015 at 04:23, Andreas Cadhalpun < > andreas.cadhal...@googlemail.com> wrote: > >> On 10.12.2015 17:42, Matt Oliver wrote: >>> Im not sure that Debian not including libcuda is a valid argument for it >>> not being a system library as thats just one OS. >> >> The GPL defines a system library only in the context of a specific >> operating system. So what is a system library differs from one OS to >> another. >> Therefore one can't just claim something is a system library and thus it's >> fine to use it, unless specifying the specific OS one talks about. >> > > So does that mean that the discussion is not so much about whether it is a > system lib or not but on what OSs it can be considered a system lib? Yes, that's the relevant topic. >> So I dont believe that just because >>> some systems dont have it doesnt stop it from being a system library. >> >> You're treating being a system library as something OS-agnostic, which >> it isn't. A library can be a system library on Windows, but not on Android. >> >> Whether or not it's a system library on Windows doesn't matter for any >> other OS. >> > > OK so by that logic does that mean we can say that it IS a system lib on > Windows and is therefore GPL compliant? If it is a system library on Windows (which I don't know), it is GPL-compatible to distribute a FFmpeg binary for Windows with nvenc enabled. > So then the issue becomes what OSs can we say it is a system lib on. > If the option is disabled by default on > these other OSs then would you agree that ffmpeg is remaining GPL compliant > and its upto the OS distributors who enable the nvenc option when packaging > ffmpeg to be doing so as they also have the appropriate nvenc system libs. Yes, the FFmpeg project doesn't distribute binaries itself, only sources, which is GPL compliant. Thus nvenc is only a potential problem for distributors of compiled ffmpeg binaries. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 10.12.2015 19:03, Nicolas George wrote: > Le decadi 20 frimaire, an CCXXIV, Andreas Cadhalpun a écrit : >> I'm not sure it's that easy. If that were correct, it would become >> GPL-compatible to distribute a GPL-licensed program linked with a >> proprietary library by simply inserting a MIT licensed header in the middle. > > But yes, it is that easy. Well, if you want to use -lfoo instead of > dlopen(), you need libfoo.so too, not just foo.h. Using the header, one could create a dummy libfoo.so containing only stub functions. > But the gist of it is that with dynamic linking, the copyleft limitations > of the GPL are trivial to circumvent. I don't think the FSF would agree [1]. > This is in fact, a good thing, because that shows that copyright is weak. > Remember that the GPL is not a good thing, it is an evil thing: using the > weapons of your enemies against them. If the weapons are weaker than > expected, so much the better. This is not about good or evil. >> The GPL-3 requires that the 'Corresponding Source' of the distributed object >> code >> is also distributed. This is defined as [1]: >> The “Corresponding Source” for a work in object code form means all the >> source >> code needed to generate, install, and (for an executable work) run the object >> code[...] > > Remember that copyright is for works of art. Art has no obligation to work. > If you can run the program until it crashes with "error while loading shared > libraries", then technically it fulfills the requirements of the GPL. > Otherwise, you would be violating the GPL each time you make a bug. The GPL does not require that programs can run, only that distributors provide the source code of everything that is needed to run the program, except system libraries. So you can distribute e.g. a GPL binary linking with libfoo.so, without distributing libfoo.so, as long as you distribute the source code of libfoo.so. However, claiming that libfoo.so is not required to run the binary would be bizarre. Best regards, Andreas 1: https://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 11 December 2015 at 04:23, Andreas Cadhalpun < andreas.cadhal...@googlemail.com> wrote: > On 10.12.2015 17:42, Matt Oliver wrote: > >> > >> What is a system library depends on the system. > >> For example, Debian (main) does not even include libcuda or > >> libnvidia-encode, so they certainly cannot be system libraries > there. > > > >> > > > > Im not sure that Debian not including libcuda is a valid argument for it > > not being a system library as thats just one OS. > > The GPL defines a system library only in the context of a specific > operating system. So what is a system library differs from one OS to > another. > Therefore one can't just claim something is a system library and thus it's > fine to use it, unless specifying the specific OS one talks about. > So does that mean that the discussion is not so much about whether it is a system lib or not but on what OSs it can be considered a system lib? > To me thats the same as > > saying that win32 stuff is not part of a system library because Debian > > doesnt have it (for obvious reasons). > > That's not correct, because Debian does have wine. ;) > lol, good point, probably wasnt the best example to use (its very late here so ill use that as an excuse for brain not working) > So I dont believe that just because > > some systems dont have it doesnt stop it from being a system library. > > You're treating being a system library as something OS-agnostic, which > it isn't. A library can be a system library on Windows, but not on Android. > > Whether or not it's a system library on Windows doesn't matter for any > other OS. > OK so by that logic does that mean we can say that it IS a system lib on Windows and is therefore GPL compliant? So then the issue becomes what OSs can we say it is a system lib on. If the option is disabled by default on these other OSs then would you agree that ffmpeg is remaining GPL compliant and its upto the OS distributors who enable the nvenc option when packaging ffmpeg to be doing so as they also have the appropriate nvenc system libs. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
Le decadi 20 frimaire, an CCXXIV, Andreas Cadhalpun a écrit : > I'm not sure it's that easy. If that were correct, it would become > GPL-compatible to distribute a GPL-licensed program linked with a > proprietary library by simply inserting a MIT licensed header in the middle. But yes, it is that easy. Well, if you want to use -lfoo instead of dlopen(), you need libfoo.so too, not just foo.h. But the gist of it is that with dynamic linking, the copyleft limitations of the GPL are trivial to circumvent. This is in fact, a good thing, because that shows that copyright is weak. Remember that the GPL is not a good thing, it is an evil thing: using the weapons of your enemies against them. If the weapons are weaker than expected, so much the better. > The GPL-3 requires that the 'Corresponding Source' of the distributed object > code > is also distributed. This is defined as [1]: > The “Corresponding Source” for a work in object code form means all the source > code needed to generate, install, and (for an executable work) run the object > code[...] Remember that copyright is for works of art. Art has no obligation to work. If you can run the program until it crashes with "error while loading shared libraries", then technically it fulfills the requirements of the GPL. Otherwise, you would be violating the GPL each time you make a bug. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 10.12.2015 17:42, Matt Oliver wrote: >> >> What is a system library depends on the system. >> For example, Debian (main) does not even include libcuda or >> libnvidia-encode, so they certainly cannot be system libraries there. > >> > > Im not sure that Debian not including libcuda is a valid argument for it > not being a system library as thats just one OS. The GPL defines a system library only in the context of a specific operating system. So what is a system library differs from one OS to another. Therefore one can't just claim something is a system library and thus it's fine to use it, unless specifying the specific OS one talks about. > To me thats the same as > saying that win32 stuff is not part of a system library because Debian > doesnt have it (for obvious reasons). That's not correct, because Debian does have wine. ;) > So I dont believe that just because > some systems dont have it doesnt stop it from being a system library. You're treating being a system library as something OS-agnostic, which it isn't. A library can be a system library on Windows, but not on Android. > And > if a system doesnt have the required propriety libs then they wont be > loaded at runtime and therefore no proprietary code is ever used at all. But distributors of compiled nvenc still have to comply with the GPL. >>> The ffmpeg binary that results from including nvEncodeAPI.h is GPL compatible because nvEncodeAPI.h is MIT licenced. >>> >>> I'm not sure it's that easy. If that were correct, it would become >>> GPL-compatible to distribute a GPL-licensed program linked with a >>> proprietary library by simply inserting a MIT licensed header in the >> middle. >> > > In this case thats not what is being said as we are not actually linking > against anything. Linking via ld.so or dlopen isn't really different from a license point of view. > As if we did link against a propriety lib then you would > be correct and this would brake GPL but that is not the case as the nvenc > binaries are only accessed at runtime. All were doing here is including a > single header file. And again: including the header is not the problem. >>> The only time the GPL ffmpeg and the proprietary licenced nvidia >> libraries are combined is on the end user system so no distribution occurs, so >> the GPL language doesn't apply at that stage. >>> >>> However, the object code compiled from nvenc.c would get distributed as >> part of >>> the ffmpeg binaries, which is governed by the GPL. >> > > The object code from nvenc.c is written using LGPL and just includes > declarations (no actual code definitions) from a MIT header file which to > me suggests that the part of ffmpeg that would be distributed is still GPL > compliant. At no point during the entire compilation and linking stage is > any proprietary component touched so I dont see how this brakes anything. However, running most of the generated object code from nvenc.c requires the non-free blobs. And the GPL specifically also requires the source code for libraries only required at run-time. > So sorry for being verbose (and potential just stating the obvious) but the > only argument here is whether we can consider the libs accessed at runtime > as system libs or not. Yes. > To use windows as a further example all the actual binary code required for > nvenc to work is part of the graphics drivers. So the only time anything > not GPL compliant is ever used is when the dll's are loaded at runtime from > the driver. This definitely puts it in the category of a system component > in my mind. If drivers are not considered system libs then we have far more > serious problems than nvenc ;) Whether or not it's a system library on Windows doesn't matter for any other OS. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 10.12.2015 17:34, Hendrik Leppkes wrote: > Am 10.12.2015 17:10 schrieb "Andreas Cadhalpun" < > andreas.cadhal...@googlemail.com>: >> If that's the only thing that allows distribution of compiled nvenc.c, >> it shouldn't be enabled by default. >> > > I don't mind disabling it by default, if that alleviates some concerns. If it's enabled by default, it could cause problems for distributors, where the system library exception doesn't apply. So not enabling it is a safer default. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
> > > I don't mind disabling it by default, if that alleviates some concerns. > One caveat to my previous comments is that just like avisynth I think that nvenc should be disabled by default aswell. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
Am 10.12.2015 17:10 schrieb "Andreas Cadhalpun" < andreas.cadhal...@googlemail.com>: > > On 10.12.2015 16:49, Hendrik Leppkes wrote: > > On Thu, Dec 10, 2015 at 4:25 PM, Andreas Cadhalpun > > wrote: > >> The GPL-3 requires that the 'Corresponding Source' of the distributed object code > >> is also distributed. This is defined as [1]: > >> The “Corresponding Source” for a work in object code form means all the source > >> code needed to generate, install, and (for an executable work) run the object > >> code[...] > >> For example, Corresponding Source includes [...] the source code for [...] > >> dynamically linked subprograms that the work is specifically designed to require, > >> such as by intimate data communication or control flow between those subprograms > >> and other parts of the work. > >> > > > > This rule does not apply to system libraries, > > Yes. > > > which I still am quite > > sure a hardware driver would fall under (and we can argue about that > > all day, you won't get any "proof" either way) > > If a particular system does not actually package this particular > > library, then their distribution of FFmpeg should probably just not > > enable nvenc, its of no use without the library anyway. > > But if it did, it would certainly not fall under the system library exception. > If that's the only thing that allows distribution of compiled nvenc.c, > it shouldn't be enabled by default. > I don't mind disabling it by default, if that alleviates some concerns. > > You could argue the same thing for QuickSync, the only difference is > > that it depends on some sort of "dispatcher" library that sits between > > FFmpeg and the closed-source library. > > Yes, that looks like a similar problem. > > > Does the existence of a tiny dispatcher library suddenly "fix" these > > rules? > > I don't think so, but I haven't looked at the code. > > > That would be silly. Yet it is widely accepted that linking > > against libmfx for qsv is fine. > > If it is 'widely accepted' that distribution of the resulting object > code is GPL compatible, then you can certainly provide links > to statements from experts saying so, e.g. from someone from the FSF. > Unless you do, 'widely accepted' is a void argument. > > Best regards, > Andreas > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
> > > >>> What is a system library depends on the system. > > >>> For example, Debian (main) does not even include libcuda or > > >>> libnvidia-encode, so they certainly cannot be system libraries there. > > >> > Im not sure that Debian not including libcuda is a valid argument for it not being a system library as thats just one OS. To me thats the same as saying that win32 stuff is not part of a system library because Debian doesnt have it (for obvious reasons). So I dont believe that just because some systems dont have it doesnt stop it from being a system library. And if a system doesnt have the required propriety libs then they wont be loaded at runtime and therefore no proprietary code is ever used at all. > > The ffmpeg binary that results from including nvEncodeAPI.h is GPL > > > compatible because nvEncodeAPI.h is MIT licenced. > > > > I'm not sure it's that easy. If that were correct, it would become > > GPL-compatible to distribute a GPL-licensed program linked with a > > proprietary library by simply inserting a MIT licensed header in the > middle. > In this case thats not what is being said as we are not actually linking against anything. As if we did link against a propriety lib then you would be correct and this would brake GPL but that is not the case as the nvenc binaries are only accessed at runtime. All were doing here is including a single header file. > > The only time the GPL ffmpeg and the proprietary licenced nvidia > libraries > > > are combined is on the end user system so no distribution occurs, so > the > > > GPL language doesn't apply at that stage. > > > > However, the object code compiled from nvenc.c would get distributed as > part of > > the ffmpeg binaries, which is governed by the GPL. > The object code from nvenc.c is written using LGPL and just includes declarations (no actual code definitions) from a MIT header file which to me suggests that the part of ffmpeg that would be distributed is still GPL compliant. At no point during the entire compilation and linking stage is any proprietary component touched so I dont see how this brakes anything. So sorry for being verbose (and potential just stating the obvious) but the only argument here is whether we can consider the libs accessed at runtime as system libs or not. To use windows as a further example all the actual binary code required for nvenc to work is part of the graphics drivers. So the only time anything not GPL compliant is ever used is when the dll's are loaded at runtime from the driver. This definitely puts it in the category of a system component in my mind. If drivers are not considered system libs then we have far more serious problems than nvenc ;) 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. > > 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. > > 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. I agree with Philip here as the nvEncodeApi header is not part of a cuda sdk install and requires a separate download. One which is not as easily accessible and one that requires a good 90MB download just to use 1 header file. Since the header is all that is needed and it is not part of a standard sdk then I think the inclusion of avisynths headers already sets a precedent to also include this one. Including it also allows ffmpeg to ensure that the correct newer MIT licensed version is the only one being used. Of course this does put the burden on ffmpeg to ensure that the header is kept up to date but as long as someone does that then I support its inclusion (I dont see an issue with keeping it up to date as anyone adding new features will inherently update it and any breakage would be a result of the interfaces changing which would brake ffmpeg anyway). So the updated patch looks good to me. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 10.12.2015 16:49, Hendrik Leppkes wrote: > On Thu, Dec 10, 2015 at 4:25 PM, Andreas Cadhalpun > wrote: >> The GPL-3 requires that the 'Corresponding Source' of the distributed object >> code >> is also distributed. This is defined as [1]: >> The “Corresponding Source” for a work in object code form means all the >> source >> code needed to generate, install, and (for an executable work) run the object >> code[...] >> For example, Corresponding Source includes [...] the source code for [...] >> dynamically linked subprograms that the work is specifically designed to >> require, >> such as by intimate data communication or control flow between those >> subprograms >> and other parts of the work. >> > > This rule does not apply to system libraries, Yes. > which I still am quite > sure a hardware driver would fall under (and we can argue about that > all day, you won't get any "proof" either way) > If a particular system does not actually package this particular > library, then their distribution of FFmpeg should probably just not > enable nvenc, its of no use without the library anyway. But if it did, it would certainly not fall under the system library exception. If that's the only thing that allows distribution of compiled nvenc.c, it shouldn't be enabled by default. > You could argue the same thing for QuickSync, the only difference is > that it depends on some sort of "dispatcher" library that sits between > FFmpeg and the closed-source library. Yes, that looks like a similar problem. > Does the existence of a tiny dispatcher library suddenly "fix" these > rules? I don't think so, but I haven't looked at the code. > That would be silly. Yet it is widely accepted that linking > against libmfx for qsv is fine. If it is 'widely accepted' that distribution of the resulting object code is GPL compatible, then you can certainly provide links to statements from experts saying so, e.g. from someone from the FSF. Unless you do, 'widely accepted' is a void argument. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On Thu, Dec 10, 2015 at 4:25 PM, Andreas Cadhalpun wrote: > On 10.12.2015 15:18, Philip Langdale wrote: >> On 2015-12-10 06:05, Andreas Cadhalpun wrote: >>> On 09.12.2015 17:38, Hendrik Leppkes wrote: On Wed, Dec 9, 2015 at 5:33 PM, Timo Rothenpieler wrote: > If I understand carl right, the question is not about the header, but > about if dlopen'ing a non-free library, the CUDA and NVENC ones in this > case, makes ffmpeg non-free, or if they are system libraries and thus > it's ok to link against them. > The generated binary contains no non-free code, not even used a non-free header, nor does it depend on any non-free binary to run. >>> >>> Well, most of the binary code generated from nvenc.c requires the >>> non-free libcuda.so and libnvidia-encode.so.1 blobs to run. >>> And even if you want to cite that particular rule - if drivers are not considered part of the system, then I don't know what is. >>> >>> What is a system library depends on the system. >>> For example, Debian (main) does not even include libcuda or >>> libnvidia-encode, so they certainly cannot be system libraries there. >> >> I am not a lawyer, etc, so make of this what you will, but: > > Neither am I and I'm not giving any legal advice here. > I just wanted to point out that the system library exception obviously > doesn't apply and since your rationale below doesn't mention it, > I think you agree. > >> The GPL controls distribution of the work and derived works because that's >> what the licence can control. > > Agreed. > >> The nvidia cuda and nvenc libraries are clearly not derived works of ffmpeg >> and the nvEncodeAPI.h is also clearly not a derived work. > > True. > >> The ffmpeg binary that results from including nvEncodeAPI.h is GPL >> compatible because nvEncodeAPI.h is MIT licenced. > > I'm not sure it's that easy. If that were correct, it would become > GPL-compatible to distribute a GPL-licensed program linked with a > proprietary library by simply inserting a MIT licensed header in the middle. > >> The only time the GPL ffmpeg and the proprietary licenced nvidia libraries >> are combined is on the end user system so no distribution occurs, so the >> GPL language doesn't apply at that stage. > > However, the object code compiled from nvenc.c would get distributed as part > of > the ffmpeg binaries, which is governed by the GPL. > >> The whole deal with proprietary drivers for the linux kernel is controversial >> because the proprietary driver can be considered a derived work of the kernel >> because it implements kernel interfaces and uses kernel code and is intended >> for use with the kernel. Clearly the nvenc library and API have no >> relationship >> with ffmpeg - they are independently developed works with other consumers and >> using them from ffmpeg does not change this fact. > > That's unrelated to the problem at hand. > >> Additionally, including nvEncodeAPI.h does not inhibit anybody's ability to >> modify or replace any part of ffmpeg as they wish, including modifying it to >> no longer have anything to do with nvenc. > > Including nvEncodeAPI.h is not causing the license problem, distributing the > object code generated from nvenc.c is. > >> So really, I'm not sure what the rationale is for thinking it's a GPL >> violation >> to include the MIT licenced nvEncodeAPI.h and to distribute a binary with >> nvenc >> support in it. I'd be interested to hear the reasoning. > > The GPL-3 requires that the 'Corresponding Source' of the distributed object > code > is also distributed. This is defined as [1]: > The “Corresponding Source” for a work in object code form means all the source > code needed to generate, install, and (for an executable work) run the object > code[...] > For example, Corresponding Source includes [...] the source code for [...] > dynamically linked subprograms that the work is specifically designed to > require, > such as by intimate data communication or control flow between those > subprograms > and other parts of the work. > This rule does not apply to system libraries, which I still am quite sure a hardware driver would fall under (and we can argue about that all day, you won't get any "proof" either way) If a particular system does not actually package this particular library, then their distribution of FFmpeg should probably just not enable nvenc, its of no use without the library anyway. You could argue the same thing for QuickSync, the only difference is that it depends on some sort of "dispatcher" library that sits between FFmpeg and the closed-source library. Does the existence of a tiny dispatcher library suddenly "fix" these rules? That would be silly. Yet it is widely accepted that linking against libmfx for qsv is fine. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 10.12.2015 15:18, Philip Langdale wrote: > On 2015-12-10 06:05, Andreas Cadhalpun wrote: >> On 09.12.2015 17:38, Hendrik Leppkes wrote: >>> On Wed, Dec 9, 2015 at 5:33 PM, Timo Rothenpieler >>> wrote: If I understand carl right, the question is not about the header, but about if dlopen'ing a non-free library, the CUDA and NVENC ones in this case, makes ffmpeg non-free, or if they are system libraries and thus it's ok to link against them. >>> >>> The generated binary contains no non-free code, not even used a >>> non-free header, nor does it depend on any non-free binary to run. >> >> Well, most of the binary code generated from nvenc.c requires the >> non-free libcuda.so and libnvidia-encode.so.1 blobs to run. >> >>> And even if you want to cite that particular rule - if drivers are not >>> considered part of the system, then I don't know what is. >> >> What is a system library depends on the system. >> For example, Debian (main) does not even include libcuda or >> libnvidia-encode, so they certainly cannot be system libraries there. > > I am not a lawyer, etc, so make of this what you will, but: Neither am I and I'm not giving any legal advice here. I just wanted to point out that the system library exception obviously doesn't apply and since your rationale below doesn't mention it, I think you agree. > The GPL controls distribution of the work and derived works because that's > what the licence can control. Agreed. > The nvidia cuda and nvenc libraries are clearly not derived works of ffmpeg > and the nvEncodeAPI.h is also clearly not a derived work. True. > The ffmpeg binary that results from including nvEncodeAPI.h is GPL > compatible because nvEncodeAPI.h is MIT licenced. I'm not sure it's that easy. If that were correct, it would become GPL-compatible to distribute a GPL-licensed program linked with a proprietary library by simply inserting a MIT licensed header in the middle. > The only time the GPL ffmpeg and the proprietary licenced nvidia libraries > are combined is on the end user system so no distribution occurs, so the > GPL language doesn't apply at that stage. However, the object code compiled from nvenc.c would get distributed as part of the ffmpeg binaries, which is governed by the GPL. > The whole deal with proprietary drivers for the linux kernel is controversial > because the proprietary driver can be considered a derived work of the kernel > because it implements kernel interfaces and uses kernel code and is intended > for use with the kernel. Clearly the nvenc library and API have no > relationship > with ffmpeg - they are independently developed works with other consumers and > using them from ffmpeg does not change this fact. That's unrelated to the problem at hand. > Additionally, including nvEncodeAPI.h does not inhibit anybody's ability to > modify or replace any part of ffmpeg as they wish, including modifying it to > no longer have anything to do with nvenc. Including nvEncodeAPI.h is not causing the license problem, distributing the object code generated from nvenc.c is. > So really, I'm not sure what the rationale is for thinking it's a GPL > violation > to include the MIT licenced nvEncodeAPI.h and to distribute a binary with > nvenc > support in it. I'd be interested to hear the reasoning. The GPL-3 requires that the 'Corresponding Source' of the distributed object code is also distributed. This is defined as [1]: The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code[...] For example, Corresponding Source includes [...] the source code for [...] dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work. Why should that not apply to the dynamically linked libcuda/libnvidia-encode? Best regards, Andreas 1: https://www.gnu.org/licenses/gpl-3.0-standalone.html ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 2015-12-09 21:34, wm4 wrote: On Mon, 7 Dec 2015 19:34:20 +0100 Timo Rothenpieler wrote: > I don't remember if this was discussed when avisynth and other headers > where included, but what's the advantage of directly including the > header and burden the FFmpeg sources, rather than asking the user to > download them in case of need? The nvenc sdk isn't exactly a common thing that distributions provide. As distributions can now easily ship ffmpeg with nvenc support, this propably helps users who now no longer need to build ffmpeg themselves for nvenc support. So why would distros build with nvenc support, if they can't even do a simple thing like installing a single header file? 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? We could just provide a download link for the nvenc header somewhere if the problem is finding the header. 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. 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. 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. 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. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 2015-12-10 06:05, Andreas Cadhalpun wrote: On 09.12.2015 17:38, Hendrik Leppkes wrote: On Wed, Dec 9, 2015 at 5:33 PM, Timo Rothenpieler wrote: If I understand carl right, the question is not about the header, but about if dlopen'ing a non-free library, the CUDA and NVENC ones in this case, makes ffmpeg non-free, or if they are system libraries and thus it's ok to link against them. The generated binary contains no non-free code, not even used a non-free header, nor does it depend on any non-free binary to run. Well, most of the binary code generated from nvenc.c requires the non-free libcuda.so and libnvidia-encode.so.1 blobs to run. And even if you want to cite that particular rule - if drivers are not considered part of the system, then I don't know what is. What is a system library depends on the system. For example, Debian (main) does not even include libcuda or libnvidia-encode, so they certainly cannot be system libraries there. I am not a lawyer, etc, so make of this what you will, but: The GPL controls distribution of the work and derived works because that's what the licence can control. The nvidia cuda and nvenc libraries are clearly not derived works of ffmpeg and the nvEncodeAPI.h is also clearly not a derived work. The ffmpeg binary that results from including nvEncodeAPI.h is GPL compatible because nvEncodeAPI.h is MIT licenced. The only time the GPL ffmpeg and the proprietary licenced nvidia libraries are combined is on the end user system so no distribution occurs, so the GPL language doesn't apply at that stage. The whole deal with proprietary drivers for the linux kernel is controversial because the proprietary driver can be considered a derived work of the kernel because it implements kernel interfaces and uses kernel code and is intended for use with the kernel. Clearly the nvenc library and API have no relationship with ffmpeg - they are independently developed works with other consumers and using them from ffmpeg does not change this fact. Additionally, including nvEncodeAPI.h does not inhibit anybody's ability to modify or replace any part of ffmpeg as they wish, including modifying it to no longer have anything to do with nvenc. So really, I'm not sure what the rationale is for thinking it's a GPL violation to include the MIT licenced nvEncodeAPI.h and to distribute a binary with nvenc support in it. I'd be interested to hear the reasoning. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 09.12.2015 17:38, Hendrik Leppkes wrote: > On Wed, Dec 9, 2015 at 5:33 PM, Timo Rothenpieler > wrote: >> If I understand carl right, the question is not about the header, but >> about if dlopen'ing a non-free library, the CUDA and NVENC ones in this >> case, makes ffmpeg non-free, or if they are system libraries and thus >> it's ok to link against them. >> > > The generated binary contains no non-free code, not even used a > non-free header, nor does it depend on any non-free binary to run. Well, most of the binary code generated from nvenc.c requires the non-free libcuda.so and libnvidia-encode.so.1 blobs to run. > And even if you want to cite that particular rule - if drivers are not > considered part of the system, then I don't know what is. What is a system library depends on the system. For example, Debian (main) does not even include libcuda or libnvidia-encode, so they certainly cannot be system libraries there. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On Wed, Dec 9, 2015 at 5:33 PM, Timo Rothenpieler wrote: Should fall under the system library stuff the GPL defines. >>> >>> I may misunderstand (I am not a native speaker) but the word >>> "should" imo indicates that you cannot commit your patch. >>> >> >> The header is licensed rather liberally and doesn't actually link >> against anything, I don't see it violating any licensing concerns. >> With other libraries where people would like to use such reasons, the >> headers are usually also license restricted, which results in quite a >> different situation. >> >> If the header should be part of FFmpeg is just a question of if we >> want it here, the license does not prevent it. >> If we decide not to commit this patch, an alternative patch should be >> pushed which removes the non-free requirement and updates the header >> version requirement. > > If I understand carl right, the question is not about the header, but > about if dlopen'ing a non-free library, the CUDA and NVENC ones in this > case, makes ffmpeg non-free, or if they are system libraries and thus > it's ok to link against them. > The generated binary contains no non-free code, not even used a non-free header, nor does it depend on any non-free binary to run. And even if you want to cite that particular rule - if drivers are not considered part of the system, then I don't know what is. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
>>> Should fall under the system library stuff the GPL defines. >> >> I may misunderstand (I am not a native speaker) but the word >> "should" imo indicates that you cannot commit your patch. >> > > The header is licensed rather liberally and doesn't actually link > against anything, I don't see it violating any licensing concerns. > With other libraries where people would like to use such reasons, the > headers are usually also license restricted, which results in quite a > different situation. > > If the header should be part of FFmpeg is just a question of if we > want it here, the license does not prevent it. > If we decide not to commit this patch, an alternative patch should be > pushed which removes the non-free requirement and updates the header > version requirement. If I understand carl right, the question is not about the header, but about if dlopen'ing a non-free library, the CUDA and NVENC ones in this case, makes ffmpeg non-free, or if they are system libraries and thus it's ok to link against them. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On Wed, Dec 9, 2015 at 3:14 PM, Carl Eugen Hoyos wrote: > Hi! > > On Monday 07 December 2015 07:37:21 pm Timo Rothenpieler wrote: >> > On Monday 07 December 2015 03:14:08 pm Timo Rothenpieler wrote: >> >> Nvidia finaly decided to put a propper MIT license on their nvenc >> >> header, so it can be included, removing any external dependencies for >> >> nvenc and making it no longer require the non-free flag. >> > >> > Please do not apply (yet)! >> > >> >> +NVENCSTATUS NVENCAPI NvEncodeAPICreateInstance() >> > >> > What is the license of the library that implements this symbol? >> > >> > Imo, it is not ok to simply circumvent a license issue by dynamic >> > loading the library. If it were that simple, it would indicate that >> > our software license can be circumvented just as easily but we were >> > quite strict (and successful) about this as long as we were able to >> > pursue license violators. >> > >> > Note that we haven't allowed this for libfaac. >> > >> > What are the steps to install this encoder library? Is it part of the >> > Nvidia binary video driver that I use for VDPAU on Linux? Is it part >> > of every Nvidia graphics driver on Windows? >> >> It comes with the binary nvidia driver on both Windows and Linux. > >> Should fall under the system library stuff the GPL defines. > > I may misunderstand (I am not a native speaker) but the word > "should" imo indicates that you cannot commit your patch. > The header is licensed rather liberally and doesn't actually link against anything, I don't see it violating any licensing concerns. With other libraries where people would like to use such reasons, the headers are usually also license restricted, which results in quite a different situation. If the header should be part of FFmpeg is just a question of if we want it here, the license does not prevent it. If we decide not to commit this patch, an alternative patch should be pushed which removes the non-free requirement and updates the header version requirement. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
>> Should fall under the system library stuff the GPL defines. > > I may misunderstand (I am not a native speaker) but the word > "should" imo indicates that you cannot commit your patch. Guess why I sent it here first... > Sorry, Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
Hi! On Monday 07 December 2015 07:37:21 pm Timo Rothenpieler wrote: > > On Monday 07 December 2015 03:14:08 pm Timo Rothenpieler wrote: > >> Nvidia finaly decided to put a propper MIT license on their nvenc > >> header, so it can be included, removing any external dependencies for > >> nvenc and making it no longer require the non-free flag. > > > > Please do not apply (yet)! > > > >> +NVENCSTATUS NVENCAPI NvEncodeAPICreateInstance() > > > > What is the license of the library that implements this symbol? > > > > Imo, it is not ok to simply circumvent a license issue by dynamic > > loading the library. If it were that simple, it would indicate that > > our software license can be circumvented just as easily but we were > > quite strict (and successful) about this as long as we were able to > > pursue license violators. > > > > Note that we haven't allowed this for libfaac. > > > > What are the steps to install this encoder library? Is it part of the > > Nvidia binary video driver that I use for VDPAU on Linux? Is it part > > of every Nvidia graphics driver on Windows? > > It comes with the binary nvidia driver on both Windows and Linux. > Should fall under the system library stuff the GPL defines. I may misunderstand (I am not a native speaker) but the word "should" imo indicates that you cannot commit your patch. Sorry, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On Mon, 7 Dec 2015 19:34:20 +0100 Timo Rothenpieler wrote: > > I don't remember if this was discussed when avisynth and other headers > > where included, but what's the advantage of directly including the > > header and burden the FFmpeg sources, rather than asking the user to > > download them in case of need? > > The nvenc sdk isn't exactly a common thing that distributions provide. > As distributions can now easily ship ffmpeg with nvenc support, this > propably helps users who now no longer need to build ffmpeg themselves > for nvenc support. So why would distros build with nvenc support, if they can't even do a simple thing like installing a single header file? 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? We could just provide a download link for the nvenc header somewhere if the problem is finding the header. > > Also: cygwin fixes should be sent upstream, rather than maintained in > > FFmpeg. > > > > This isn't primarily about cygwin support. The change is just || > defined(__CYGWIN__) that's added to one #if. > Also, sending patches upstream might take years or could be ignored > entirely. > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
> On Monday 07 December 2015 03:14:08 pm Timo Rothenpieler wrote: >> Nvidia finaly decided to put a propper MIT license on their nvenc header, >> so it can be included, removing any external dependencies for nvenc and >> making it no longer require the non-free flag. > > Please do not apply (yet)! > >> +NVENCSTATUS NVENCAPI NvEncodeAPICreateInstance() > > What is the license of the library that implements this symbol? > > Imo, it is not ok to simply circumvent a license issue by dynamic > loading the library. If it were that simple, it would indicate that > our software license can be circumvented just as easily but we were > quite strict (and successful) about this as long as we were able to > pursue license violators. > > Note that we haven't allowed this for libfaac. > > What are the steps to install this encoder library? Is it part of the > Nvidia binary video driver that I use for VDPAU on Linux? Is it part > of every Nvidia graphics driver on Windows? It comes with the binary nvidia driver on both Windows and Linux. Should fall under the system library stuff the GPL defines. I don't recall anyone worrying about that so far. It allways was about the restrictive license the nvEncodeAPI.h header had. > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
> I don't remember if this was discussed when avisynth and other headers > where included, but what's the advantage of directly including the > header and burden the FFmpeg sources, rather than asking the user to > download them in case of need? The nvenc sdk isn't exactly a common thing that distributions provide. As distributions can now easily ship ffmpeg with nvenc support, this propably helps users who now no longer need to build ffmpeg themselves for nvenc support. > Also: cygwin fixes should be sent upstream, rather than maintained in > FFmpeg. > This isn't primarily about cygwin support. The change is just || defined(__CYGWIN__) that's added to one #if. Also, sending patches upstream might take years or could be ignored entirely. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On Monday 07 December 2015 03:14:08 pm Timo Rothenpieler wrote: > Nvidia finaly decided to put a propper MIT license on their nvenc header, > so it can be included, removing any external dependencies for nvenc and > making it no longer require the non-free flag. Please do not apply (yet)! > +NVENCSTATUS NVENCAPI NvEncodeAPICreateInstance() What is the license of the library that implements this symbol? Imo, it is not ok to simply circumvent a license issue by dynamic loading the library. If it were that simple, it would indicate that our software license can be circumvented just as easily but we were quite strict (and successful) about this as long as we were able to pursue license violators. Note that we haven't allowed this for libfaac. What are the steps to install this encoder library? Is it part of the Nvidia binary video driver that I use for VDPAU on Linux? Is it part of every Nvidia graphics driver on Windows? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 12/7/2015 3:09 PM, Timo Rothenpieler wrote:
>>> @@ -1603,6 +1603,7 @@ CONFIG_LIST="
>>> memalign_hack
>>> memory_poisoning
>>> neon_clobber_test
>>> +nvenc
>>
>> You forgot to remove nvenc from EXTERNAL_LIBRARY_LIST
>
> Yep, forgot about that.
>
>>> +case $target_os in
>>> +mingw32*|mingw64*|win32|win64|linux|cygwin*)
>>> +disabled nvenc || enable nvenc
>>> +;;
>>> +*)
>>> +disable nvenc
>>> +;;
>>> +esac
>>> +
>>> +if enabled nvenc; then
>>> +{
>>> +echo '#include "nvenc.h"'
>>> +echo 'int main(void) { return 0; }'
>>> +} | check_cc -I$source_path/libavcodec ||
>>> +disable nvenc
>>> +fi
>>> +
>>
>> Is this check even needed when you're checking for compatible OSes above?
>> Not to mention nvenc.h only includes stdlib.h and then typedefs everything
>> it needs, which makes me think it should compile for any target out there.
>
> It's kind of a sanity check to make sure it builds with the compiler
> that's beeing used, in case it doesn't work on some weird/old compiler.
> If that's not a concern, this check can be removed.
It seems to include stdlib.h for every target, then windows.h on _WIN32 and
stdint.h on MSVC.
It also apparently makes the assumption that stdlib.h alone is enough to get
all the fixed-width integer types, which may not be true for all ffmpeg targets,
so i guess this check is the safest thing to do after all.
>
>> In any case, do instead something like
>>
>> enabled nvenc &&
>> check_cc -I$source_path/libavcodec <> #include "nvenc.h"
>> int x;
>> EOF
>
> Doesn't check_cc need a main function? Or is it just about the EOF style
> vs. { echo }?
No, look at the dxva2api_h check below. And yes, it's about the EOF style, which
is more consistent with the rest of the checks.
>> [...]
>>
>>> diff --git a/libavcodec/nvenc.h b/libavcodec/nvenc.h
>>> new file mode 100644
>>> index 000..8b67c11
>>> --- /dev/null
>>> +++ b/libavcodec/nvenc.h
>>
>> compat/nvenc/nvenc.h? It's the proper place for non ffmpeg headers, like we
>> do with Avisynth.
>
> Yes, will move it there.
>
>> Or maybe both nvenc and the Avisynth stuff could be moved to a new "contrib"
>> or "thirdparty" folder.
>
> That's out of the scope of this patch, but sounds like a good idea to me.
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On date Monday 2015-12-07 14:53:22 -0300, James Almer encoded: > On 12/7/2015 11:14 AM, Timo Rothenpieler wrote: > > Nvidia finaly decided to put a propper MIT license on their nvenc header, so > > it can be included, removing any external dependencies for nvenc and > > making it no longer require the non-free flag. > > > > nvenc.h is the original nvEncodeApi.h from the NVENC SDK 6.0.1, with a > > slight modification to make it work on cygwin. > > --- > > configure | 25 +- > > libavcodec/nvenc.c |2 +- > > libavcodec/nvenc.h | 3122 > > > > 3 files changed, 3142 insertions(+), 7 deletions(-) > > create mode 100644 libavcodec/nvenc.h [...] > > diff --git a/libavcodec/nvenc.h b/libavcodec/nvenc.h > > new file mode 100644 > > index 000..8b67c11 > > --- /dev/null > > +++ b/libavcodec/nvenc.h > > compat/nvenc/nvenc.h? It's the proper place for non ffmpeg headers, like we > do with Avisynth. > Or maybe both nvenc and the Avisynth stuff could be moved to a new "contrib" > or "thirdparty" folder. I don't remember if this was discussed when avisynth and other headers where included, but what's the advantage of directly including the header and burden the FFmpeg sources, rather than asking the user to download them in case of need? Also: cygwin fixes should be sent upstream, rather than maintained in FFmpeg. -- FFmpeg = Fascinating and Fundamentalist Magical Purposeless Encoding/decoding Game ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
>> @@ -1603,6 +1603,7 @@ CONFIG_LIST="
>> memalign_hack
>> memory_poisoning
>> neon_clobber_test
>> +nvenc
>
> You forgot to remove nvenc from EXTERNAL_LIBRARY_LIST
Yep, forgot about that.
>> +case $target_os in
>> +mingw32*|mingw64*|win32|win64|linux|cygwin*)
>> +disabled nvenc || enable nvenc
>> +;;
>> +*)
>> +disable nvenc
>> +;;
>> +esac
>> +
>> +if enabled nvenc; then
>> +{
>> +echo '#include "nvenc.h"'
>> +echo 'int main(void) { return 0; }'
>> +} | check_cc -I$source_path/libavcodec ||
>> +disable nvenc
>> +fi
>> +
>
> Is this check even needed when you're checking for compatible OSes above?
> Not to mention nvenc.h only includes stdlib.h and then typedefs everything
> it needs, which makes me think it should compile for any target out there.
It's kind of a sanity check to make sure it builds with the compiler
that's beeing used, in case it doesn't work on some weird/old compiler.
If that's not a concern, this check can be removed.
> In any case, do instead something like
>
> enabled nvenc &&
> check_cc -I$source_path/libavcodec < #include "nvenc.h"
> int x;
> EOF
Doesn't check_cc need a main function? Or is it just about the EOF style
vs. { echo }?
> [...]
>
>> diff --git a/libavcodec/nvenc.h b/libavcodec/nvenc.h
>> new file mode 100644
>> index 000..8b67c11
>> --- /dev/null
>> +++ b/libavcodec/nvenc.h
>
> compat/nvenc/nvenc.h? It's the proper place for non ffmpeg headers, like we
> do with Avisynth.
Yes, will move it there.
> Or maybe both nvenc and the Avisynth stuff could be moved to a new "contrib"
> or "thirdparty" folder.
That's out of the scope of this patch, but sounds like a good idea to me.
signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 12/7/2015 11:14 AM, Timo Rothenpieler wrote:
> Nvidia finaly decided to put a propper MIT license on their nvenc header, so
> it can be included, removing any external dependencies for nvenc and
> making it no longer require the non-free flag.
>
> nvenc.h is the original nvEncodeApi.h from the NVENC SDK 6.0.1, with a
> slight modification to make it work on cygwin.
> ---
> configure | 25 +-
> libavcodec/nvenc.c |2 +-
> libavcodec/nvenc.h | 3122
>
> 3 files changed, 3142 insertions(+), 7 deletions(-)
> create mode 100644 libavcodec/nvenc.h
>
> diff --git a/configure b/configure
> index a731712..f33b7c4 100755
> --- a/configure
> +++ b/configure
> @@ -279,7 +279,7 @@ External library support:
>--disable-lzma disable lzma [autodetect]
>--enable-decklinkenable Blackmagic DeckLink I/O support [no]
>--enable-mmalenable decoding via MMAL [no]
> - --enable-nvenc enable NVIDIA NVENC support [no]
> + --disable-nvenc disable NVIDIA NVENC support [autodetect]
>--enable-openal enable OpenAL 1.1 capture support [no]
>--enable-opencl enable OpenCL code
>--enable-opengl enable OpenGL rendering [no]
> @@ -1603,6 +1603,7 @@ CONFIG_LIST="
> memalign_hack
> memory_poisoning
> neon_clobber_test
> +nvenc
You forgot to remove nvenc from EXTERNAL_LIBRARY_LIST
> pic
> pod2man
> raise_major
> @@ -4807,7 +4808,6 @@ die_license_disabled gpl x11grab
>
> die_license_disabled nonfree libaacplus
> die_license_disabled nonfree libfaac
> -die_license_disabled nonfree nvenc
> enabled gpl && die_license_disabled_gpl nonfree libfdk_aac
> enabled gpl && die_license_disabled_gpl nonfree openssl
>
> @@ -5502,10 +5502,6 @@ enabled mmal && { check_lib
> interface/mmal/mmal.h mmal_port_connect
> check_lib interface/mmal/mmal.h
> mmal_port_connect ; }
> check_lib interface/mmal/mmal.h
> mmal_port_connect ; } ||
> die "ERROR: mmal not found"; }
> -enabled nvenc && { check_header nvEncodeAPI.h || die "ERROR:
> nvEncodeAPI.h not found."; } &&
> - { check_cpp_condition nvEncodeAPI.h
> "NVENCAPI_MAJOR_VERSION >= 5" ||
> - die "ERROR: NVENC API version 4 or older is
> not supported"; } &&
> - { [ $target_os != cygwin ] || die "ERROR: NVENC
> is not supported on Cygwin currently."; }
> enabled openal&& { { for al_libs in "${OPENAL_LIBS}" "-lopenal"
> "-lOpenAL32"; do
> check_lib 'AL/al.h' alGetError "${al_libs}"
> && break; done } ||
> die "ERROR: openal not found"; } &&
> @@ -5663,6 +5659,23 @@ if enabled x11grab; then
> require Xfixes X11/extensions/Xfixes.h XFixesGetCursorImage -lXfixes
> fi
>
> +case $target_os in
> +mingw32*|mingw64*|win32|win64|linux|cygwin*)
> +disabled nvenc || enable nvenc
> +;;
> +*)
> +disable nvenc
> +;;
> +esac
> +
> +if enabled nvenc; then
> +{
> +echo '#include "nvenc.h"'
> +echo 'int main(void) { return 0; }'
> +} | check_cc -I$source_path/libavcodec ||
> +disable nvenc
> +fi
> +
Is this check even needed when you're checking for compatible OSes above?
Not to mention nvenc.h only includes stdlib.h and then typedefs everything
it needs, which makes me think it should compile for any target out there.
In any case, do instead something like
enabled nvenc &&
check_cc -I$source_path/libavcodec < diff --git a/libavcodec/nvenc.h b/libavcodec/nvenc.h
> new file mode 100644
> index 000..8b67c11
> --- /dev/null
> +++ b/libavcodec/nvenc.h
compat/nvenc/nvenc.h? It's the proper place for non ffmpeg headers, like we
do with Avisynth.
Or maybe both nvenc and the Avisynth stuff could be moved to a new "contrib"
or "thirdparty" folder.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
