[Feature request] NVENC support

[thesword53]

Do you plan to add encoding support via NVENC?

[elFarto]

Originally I had planned to look into it, but I'm not so sure now. I don't know if hardware video encoding is useful for the very few programs that can actually make use of this library.

[exalented]

Sway/Nvidia user here. This is the only working solution for hardware accel for me. Sunshine comes to mind. Would be amazing to have NVENC.

[NoTuxNoBux]

Since Firefox can use the driver, would supporting encoding also open up hardware-accelerated encoding for screen sharing or sharing webcam video in conferencing solutions such as Jitsi / Microsoft Teams / Google Meet / ...?

[thesword53]

It would also be useful for Virgl video encoding: https://www.phoronix.com/news/Virgl-Encode-H264-H265

[exalented]

Any news on this? I'll pitch in $50.

[elFarto]

I did take a quick look at it. NVENC looks pretty straight forward to use, but I struggled to understand how to use VA-API to encode. From what I can tell, the mapping between the two isn't as straight forward as the decoding side is.

[JeWe37]

I also have a use for this, I use multiple different machines for hardware encoding, some of which have NVIDIA, others Intel and others again AMD GPUs, and having VA-API support on NVIDIA would drastically simplify the required ffmpeg command creation.

[BlauerHunger]

Waypipe could also benefit from this

[cl0vrfi3ld]

I've been running a media server on my k8s cluster and configuring the current non-free NVIDIA drivers to work with containers/k8s was a nightmare, just to get basic hardware encoding working. It requires installing a custom container runtime (nvidia-container-toolkit), re-configuring (and in my case re-installing) Kubernetes, and installing extra operators in the cluster that take up compute resources and aren't documented that well. With VA-API GPUs, though, it's as simple as binding your workload to the appropriate dri path on the host, just like binding a directory. Voila, your GPU is exposed to the container.

This is all to say, having full decode and encode support would be HUGE for those utilizing containers. I can't support development financially at this time, but I'm happy to help out in any way I can (seriously this driver would've saved me days of tinkering, though I may just be bad at managing Linux kernel stuff 😅).

[polarathene]

FWIW, the way forward with containers is CDI (standardised with OCI, so CRI agnostic), but presently only nvidia has official support for this (there is third-party generator for AMD iirc).

With docker prior to CDI, effectively only nvidia was supported (officially), and only cuda (compute) and nvidia-smi (utilities) capabilities were enabled by default.

Video encoding required an extra capability enabled and thus more verbose config similar to what you'd do for amd. Otherwise it's just --gpus all on the CLI, the runtime you mention would be seamless (at least on Windows) with Docker Desktop which sets that up behind the scenes (they have k3s which might leverage the same).

Anyway, with CDI the host system needs a config for the hardware defined with mappings of what to mount/do. It is vendor agnostic and allows for effectively --device nvidia.com/all (something like that iirc).

NixOS has a package for AMD and maybe Intel that's third-party/community managed iirc, and k8s AFAIK has equivalent via some plugins (I don't use k8s so I can't assist much there).

I'm not sure how long broader adoption for CDI by gpu vendors will take. I don't think it requires the custom nvidia runtime, but if it does pretty sure it's not intended to stay that way, it does currently require a host package (nvidia ctk) to generate the CDI config however.

[padoruuuu]

id personally send el farto 200 bucks if nvenc support could be worked out