[FFmpeg-trac] #6405(undetermined:new): Compile troubles with “cuvid”, “nvenc” and “npp”

[FFmpeg]

#6405: Compile troubles with “cuvid”, “nvenc” and “npp”
-------------------------------------+-------------------------------------
             Reporter:  ahakon       |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
              Version:  git-master   |  undetermined
             Keywords:  cuvid,       |               Resolution:
  nvenc, npp, cuda-sdk               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by ahakon):

 Hi Oromit,

 Replying to [comment:5 oromit]:
 > I have no idea what you are going at, to build the scale_npp filter, you
 need libraries and headers that are part of the CUDA SDK, not of the set
 of re-implemented headers ffmpeg supplies, which is what the cuda
 dependency in configure ultimately means.
 > The cuda_sdk dependency was newly introduced and libnpp updated for them
 accordingly.

 Sorry. I try to explain more...

 If you compile FFmpeg configuring it with "--enable-cuda-sdk" then the
 link process adds "-lcuda". The result is a binary with a dynamic
 dependency to "libnvidia-fatbinaryloader.so.XXX.YY" (check it with ldd),
 where XXX.YY is your current driver version.

 However, this dynamic dependency is superfluous. Because the current
 headers included in the source of the FFmpeg have the code to load at run-
 time the functions exported by the shared library "libcuda.so.1". And this
 file is installed by the driver, and has the same name despite the current
 installed driver.

 One example of the same is the "n264_nvenc" component of the FFmpeg. This
 module uses 'some' libcuda functions, but when it is enabled in the
 compilation, the configuration not triggers the CUDA SDK (so, it not adds
 "-lcuda").

 And the same is true when you compile with the "scale_npp" filter. This
 filter uses 'some' libnpp* functions. These functions are linked directly,
 and not through the "libnvidia-fastbinaryloader.so". Instead, the same
 functions are loaded at run-time from the library "libcuda.so.1".

 The result is: the ancient configuration for the "scale_npp" filter is
 correct ("cuda libnpp") and the current is superfluous ("cuda_sdk
 libnpp").

 If you like to check it, try to recompile FFmpeg with "--enable-libnpp
 --enable-cuda --disable-cuda-sdk" and the CUDA SDK installed. If you
 revert the configuration to [scale_npp_filter_deps="cuda libnpp"], then
 you show that all works as expected. Why then force to link with CUDA SDK?
 If you really like to do it, you can do it (--enable-cuda-sdk). However,
 this is not required to compile the "scale_npp" filter.

 Moreover, these problems are created by the current configuration:

 1) After compile FFmpeg with "scale_npp" enabled, if you change the NV
 driver, then you need to recompile (without the "cuda_sdk" requirement
 this problem doesn't appear).

 2) If you compile FFmpeg with the static version of the libnpp* libraries
 (/usr/local/lib/*_static.a), then even if you enable the scale_npp filter,
 your binary only requires "libcuda.so.1" at run-time.

 So, the conclusion is quite simple: It's best to use
 [scale_npp_filter_deps="cuda libnpp"] in the configuration file.



 Replying to [comment:5 oromit]:
 > I agree that the minimum required driver version should be indicated in
 some place visible from a libavcodec binary. Might just add it to the
 error message when encoder initialization fails, but that might confuse
 people, as there are numerous reasons why that function might fail.


 Great. Perhaps it's best to start with a simple comment in the source
 code.
 You agree?

--
Ticket URL: <https://trac.ffmpeg.org/ticket/6405#comment:6>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker