VIDEO_CARDS=nvidia enables nvenc encoder, but without CUDA support all I got was CUDA initialization fail for unknown reason which is not really helpful. The uvm use flag fixes it for me.
If depending is too much, perhaps a suggestion post install to enable uvm flag.
Steps to Reproduce:
Run ffmpeg with h264_nvenc encoder
Yes, this is indeed needed for the likes of nvenc.
Not up to me but I don't like the idea of making nvidia users enable uvm and pull opencl deps (especially the default one using ruby) when most people don't even use nvenc. They would likely sooner enable it for nothing than try to disable VIDEO_CARDS="nvidia"
Always felt this should have its own off-by-default USE (also notably because it conflicts for 390.xx nvidia-drivers user). Like USE=nvcodec or a more recognizable USE=nvenc
But a simple alternative could be to just emit a optfeature warning I guess. If do add [uvm] maybe(?) it'd belong in nv-codec-headers instead though (it already depends on nvidia-drivers).
A separate useflag for ffmpeg actually sounds good to me. I agree when people define VIDEO_CARDS=nvidia they don't necessarily want nvenc.
Way back in 2015, the first ffmpeg ebuild patches for nvenc in #542726 did in fact name the flag USE=nvenc. I'm not sure when or why that was later changed to video_cards_nvidia.
IMO, VIDEO_CARDS should in general control only selection of video output related drivers/features. By that I mean support for CRTC control / modesetting, 2d raster output, 2d acceleration, hardware 3d rendering, and hardware video *decoding*. Having VIDEO_CARDS also control support for auxiliary non-output features like hardware video encoding never really made sense to me.
FWIW, I don't think that media-video/ffmpeg should pull in x11-drivers/nvidia-drivers at all. ffmpeg with nvenc enabled will build and run just fine without nvidia-drivers installed unless you actually try to use nvenc at runtime. Otherwise, it only needs media-libs/nv-codec-headers at build time.
Having ffmpeg pull in x11-drivers/nvidia-drivers anyway - as per current behavior - actually causes notable problems when Portage binary packages are involved:
1) nvidia-drivers will fail to build if a compatible kernel source tree is not present. This winds up being a recurring problem for binary package build chroots.
2) Installing a common ffmpeg binary package that was built with nvenc support enabled will force the installation of nvidia-drivers on client machines which don't even have NVidia cards. These ffmpeg binaries work perfectly fine with neither the NVidia drivers nor hardware installed, so there is no good reason to force installation of the drivers by having media-video/ffmpeg RDEPEND on x11-drivers/nvidia-drivers.
Here's the relevant real-world scenario: I build and deploy in-house Portage binaries across ~70 University systems...
Due to #1, my build chroots need to have x11-drivers/nvidia-drivers-999 in their package.provided to ensure that building ffmpeg with nvenc support doesn't cause the whole build to break during just about every release cycle.
Due to #2, every client machine that doesn't have an NVidia card also needs to have x11-drivers/nvidia-drivers-999 in its package.provided.
Ultimately, the only machines that *don't* wind up needing nvidia-drivers in package.provided are the subset of client machines which do actually have NVidia cards.