[FFmpeg-devel] [PATCH] configure: support static libnpp [v2]
andreas.hakon at protonmail.com
Fri Jun 2 14:47:31 EEST 2017
Sorry, but ProtonMail has troubles with "non-top" replies...
-------- Original Message --------
Subject: Re: [FFmpeg-devel] [PATCH] configure: support static libnpp [v2]
Local Time: June 2, 2017 12:03 PM
UTC Time: June 2, 2017 10:03 AM
From: h.leppkes at gmail.com
To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
On Fri, Jun 2, 2017 at 11:56 AM, Andreas Håkon
<andreas.hakon at protonmail.com> wrote:
> Hi Hendrik,
> I don't like that there is a separate configure option. We can link to
> other libraries dynamically or statically depending on what is found,
> without needing two configure options per library.
> I understand. However, this is not really true for libnpp*.
> Let me to explain about this special case:
> If you like to compile FFmpeg statically you can do it. However, you link all or none.
> And in the case of libnpp* if you link with regular shard objects, then you need to have all CUDA SDK libraries installed in your computer.
> However, if you link to the static version of this library then you need to install only the NVidia driver.
> The trick is the dynamic loading of the library "libcuda.so.1" in the source code of the "dynalink_loader.h".
> Please, review my description about this special case at: http://trac.ffmpeg.org/ticket/6405
> So, this patch simplifies a lot the use of the libnpp functions (like the 'scale_npp').
> More or less, is similar to the use of "nvenc_*" in FFmpeg. By default it doesn't link dynamic with CUDA, as the "dynalink_loader.h" has the code to load the functions from the shared library provided by the DRIVER, not the CUDA lib (the shared object "libcuda.so.1" is provided by the DRIVER, and not by the SDK).
> In fact, the CUDA shared library is a mere wrapper to load some functions. These functions can be in shared objects or in static libraries.
> Then, if you like to compile a regular FFmpeg with shared objects and dependent to the NVidia DRIVER, but not with the CUDA SDK, you can use this patch.
> I hope you agree this explanation. This patch is really useful.
I don't dispute that static linking might be useful, but I'm still not
liking needing a separate configure option, if perhaps another
solution can be found.
However, one thing to remember is that you need to build FFmpeg as
non-free for this, so you are not allowed to distribute these
binaries. So one might argue that when you need the CUDA SDK during
build time, and you cannot distribute these binaries, then what
advantage is there?
Please don't top post on this mailing list.
ffmpeg-devel mailing list
ffmpeg-devel at ffmpeg.org
> I don't dispute that static linking might be useful, but I'm still not
> liking needing a separate configure option, if perhaps another
> solution can be found.
I'm glad if you point me in to another solution.
Meanwhile this solution is simple and effective.
> However, one thing to remember is that you need to build FFmpeg as
> non-free for this, so you are not allowed to distribute these
> binaries. So one might argue that when you need the CUDA SDK during
> build time, and you cannot distribute these binaries, then what
> advantage is there?
True. Non-free is required to be enabled. However, some advantages exists:
1) If you link libnpp* static (with this patch) you can upgrade the NVidia driver and the CUDA SDK without recompiling the FFmpeg. The main advantage is this.
2) If you link libnpp* static you can uninstall the CUDA SDK after compile the FFmpeg. It doesn't need the SDK to run. Then you can save (a lot of) space.
3) Even if you compile FFmpeg with "non-free" enabled, you can use the binary in any machine you own. You can't distribute the binary, but you can copy/use the binary. So, if you have a cluster of machines, you only need to copy the binary, install the NVidia driver, and... nothing more. The CUDA SDK is not a requirement for run FFmpeg, only to compile it.
You agree with these advantages?
Sent with [ProtonMail](
) Secure Email.
More information about the ffmpeg-devel