| Message ID | M2gbTv7jGBuQrW_3M3pGDFqFykTC3JogLbjwSXJZF9t8z9DBZgDhGBS7kHtjhUQfIjRE5JklS08PGXml37ndVqnTzT3WXZW4VBSJgLo0I9Y=@protonmail.com |
|---|---|
| State | Superseded |
| Headers | show |
On Fri, Jun 2, 2017 at 10:56 AM, Andreas Håkon <andreas.hakon@protonmail.com> wrote: > Hi, > > This patch is based on the original work done by Timo Rothenpieler, and his patch for static linking with libnpp: > [http://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195078.html](https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195078.html) > > Based in my recomendations now it's possible to link directly to libnpp* libraries without linking to the CUDA SDK: > [http://trac.ffmpeg.org/ticket/6405](https://trac.ffmpeg.org/ticket/6405) > http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=2d978d1c721ae69a9007b530153067736d4ddc79 > > Then I created an updated version of the patch. > > By default the linking is the regular dynamic link (aka "--disable-libnpp-static" config). > However, if you like to compile statically with "libnpp*_static.a" then add these parameters: > $ configure ... --enable-nonfree --enable-libnpp --enable-libnpp-static --enable-cuda --extra-cflags="-I/usr/local/cuda/include/" --extra-ldflags="-L/usr/local/cuda/lib64/" > > This assumes the CUDA SDK is installed in "/usr/local/cuda". 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. - Hendrik
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. Regards, A.H. Sent with [ProtonMail](https://protonmail.com) Secure Email. -------- Original Message -------- Subject: Re: [FFmpeg-devel] [PATCH] configure: support static libnpp [v2] Local Time: June 2, 2017 11:04 AM UTC Time: June 2, 2017 9:04 AM From: h.leppkes@gmail.com To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> On Fri, Jun 2, 2017 at 10:56 AM, Andreas Håkon <andreas.hakon@protonmail.com> wrote: > Hi, > > This patch is based on the original work done by Timo Rothenpieler, and his patch for static linking with libnpp: > [http://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195078.html](https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195078.html) > > Based in my recomendations now it's possible to link directly to libnpp* libraries without linking to the CUDA SDK: > [http://trac.ffmpeg.org/ticket/6405](https://trac.ffmpeg.org/ticket/6405) > http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=2d978d1c721ae69a9007b530153067736d4ddc79 > > Then I created an updated version of the patch. > > By default the linking is the regular dynamic link (aka "--disable-libnpp-static" config). > However, if you like to compile statically with "libnpp*_static.a" then add these parameters: > $ configure ... --enable-nonfree --enable-libnpp --enable-libnpp-static --enable-cuda --extra-cflags="-I/usr/local/cuda/include/" --extra-ldflags="-L/usr/local/cuda/lib64/" > > This assumes the CUDA SDK is installed in "/usr/local/cuda". 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. - Hendrik
On Fri, Jun 2, 2017 at 11:56 AM, Andreas Håkon <andreas.hakon@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? PS: Please don't top post on this mailing list. - Hendrik
Sent with [ProtonMail](https://protonmail.com) Secure Email. -------- 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@gmail.com To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> On Fri, Jun 2, 2017 at 11:56 AM, Andreas Håkon <andreas.hakon@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? PS: Please don't top post on this mailing list. - Hendrik
Hi, 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@gmail.com To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> On Fri, Jun 2, 2017 at 11:56 AM, Andreas Håkon <andreas.hakon@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? PS: Please don't top post on this mailing list. - Hendrik
Hi Henry, (repost without quotes... sorry!) > 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? Regards. A.H.
diff --git a/configure b/configure index 72060ef..4eac083 100755 --- a/configure +++ b/configure @@ -300,6 +300,7 @@ External library support: --disable-dxva2 disable Microsoft DirectX 9 video acceleration code [autodetect] --enable-libmfx enable Intel MediaSDK (AKA Quick Sync Video) code via libmfx [no] --enable-libnpp enable Nvidia Performance Primitives-based code [no] + --disable-libnpp-static disable using static version of libnpp [autodetect] --enable-mmal enable Broadcom Multi-Media Abstraction Layer (Raspberry Pi) via MMAL [no] --disable-nvenc disable Nvidia video encoding code [autodetect] --enable-omx enable OpenMAX IL code [no] @@ -1599,6 +1600,7 @@ HWACCEL_AUTODETECT_LIBRARY_LIST=" HWACCEL_LIBRARY_NONFREE_LIST=" cuda_sdk libnpp + libnpp_static " HWACCEL_LIBRARY_LIST=" @@ -5816,7 +5818,15 @@ enabled libmfx && { use_pkg_config libmfx "mfx/mfxvideo.h" MFXInit || { require libmfx "mfx/mfxvideo.h" MFXInit -llibmfx && warn "using libmfx without pkg-config"; } } enabled libmodplug && require_pkg_config libmodplug libmodplug/modplug.h ModPlug_Load enabled libmp3lame && require "libmp3lame >= 3.98.3" lame/lame.h lame_set_VBR_quality -lmp3lame -enabled libnpp && require libnpp npp.h nppGetLibVersion -lnppi -lnppc +enabled libnpp && { { if ! disabled libnpp_static; then + check_lib npp.h nppGetLibVersion -lnppi_static -lnppc_static -lcudart_static -lculibos $ldl || + check_lib npp.h nppGetLibVersion -lnppi_static -lnppc_static -lcudart_static -lculibos $ldl -lstdc++ || + check_lib npp.h nppGetLibVersion -lnppi_static -lnppc_static -lcudart_static -lculibos $ldl -lstdc++ -lrt + else false; fi; } || + { if ! enabled libnpp_static; then + check_lib npp.h nppGetLibVersion -lnppi -lnppc + else false; fi; } || + die "ERROR: libnpp not found"; } enabled libopencore_amrnb && require libopencore_amrnb opencore-amrnb/interf_dec.h Decoder_Interface_init -lopencore-amrnb enabled libopencore_amrwb && require libopencore_amrwb opencore-amrwb/dec_if.h D_IF_init -lopencore-amrwb enabled libopencv && { check_header opencv2/core/core_c.h &&
Hi, This patch is based on the original work done by Timo Rothenpieler, and his patch for static linking with libnpp: [http://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195078.html](https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195078.html) Based in my recomendations now it's possible to link directly to libnpp* libraries without linking to the CUDA SDK: [http://trac.ffmpeg.org/ticket/6405](https://trac.ffmpeg.org/ticket/6405) http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=2d978d1c721ae69a9007b530153067736d4ddc79 Then I created an updated version of the patch. By default the linking is the regular dynamic link (aka "--disable-libnpp-static" config). However, if you like to compile statically with "libnpp*_static.a" then add these parameters: $ configure ... --enable-nonfree --enable-libnpp --enable-libnpp-static --enable-cuda --extra-cflags="-I/usr/local/cuda/include/" --extra-ldflags="-L/usr/local/cuda/lib64/" This assumes the CUDA SDK is installed in "/usr/local/cuda". Regards. A.H. From db73653ea3da9478ac012e4d143b8c6551acb06b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andreas=20H=C3=A5kon?= <andreas.hakon@protonmail.com> Date: Fri, 2 Jun 2017 09:35:03 +0100 Subject: [PATCH] configure: support static libnpp [v2] --- configure | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)