A concrete use case for the gpu capability, from a package on the community catalogue (ca.cloudron.io).
WeaveSignal (top.weavesignal.cloudronapp, AGPL-3.0) is an internet radio and video studio: a live room with presenters and callers, a mixing desk, playout and the listener streams in one app. Its desk can also make a live video stream: it cuts between the cameras of whoever is speaking and encodes AV1 into CMAF HLS behind the same profanity delay as the sound.
Today, in the Cloudron package, the video path runs on the CPU (SVT-AV1). That is fine at one 480p rung: four cameras took the desk from 11 % to 27 % of one core on a workstation.
With an NVIDIA GPU the desk uses NVENC for AV1, one encoder session per rung (a GeForce card allows 12 per machine). On our Compose bundle that is --device nvidia.com/gpu=all, which is CDI already. In the Cloudron app it would be the proposed gpu capability, with nothing else on the app's side: the desk tries NVENC and falls back to SVT-AV1 on its own.
What a GPU buys a station: several rungs (480p, 360p, 240p) at no extra CPU. It also leaves the CPU free for the audio. That matters more to us than the video, because the desk and Liquidsoap hand audio on every 10 to 20 ms, and a starved host is heard at once.
We can test it on real hardware: a GeForce RTX 5090 with driver 615.78 and the NVIDIA Container Toolkit, on a Cloudron test install, as soon as there is a build or a branch to try. I can report back here with the encoder's session count and the CPU figures with and without the capability.
A question on vaapi: does it hand the container the render node (/dev/dri/renderD128) with the permissions an unprivileged process needs to encode, not only decode? Intel Arc and recent AMD cards encode AV1 through VA-API, and we could support those with the capability that exists today.
Thank you for considering it, and for Cloudron.
