From d22ce0ba5aebfff5ffaea97982472f876af5da22 Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Fri, 18 Sep 2026 14:37:08 +0200 Subject: feat: decode and re-encode video on the GPU where there is one MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A 1080p film is decoded by whoever watches it and re-encoded by the node when no browser can decode the source. Both were on the CPU, and on an Atom or Celeron mini-PC neither reaches real time — which is what `transcode_incompatible_video` exists to refuse. This adds the mechanism that makes refusing it unnecessary. Node — `hwaccel.py`: VA-API on Linux, Quick Sync or NVENC on Windows, established by encoding 1080p and reading the file back with ffprobe. Nothing is accepted that does not produce the exact profile and level `stream_init` announces, since the client checks that string before it trusts a byte: an encoder that wrote another level would make the node's own codec string a lie, and ffmpeg takes `-level 4.1` and `-level 41` from h264_qsv without saying which it understood. Three modes per stream — hardware decode and encode, hardware encode alone, libx264 — demoted per source codec, because a GPU that decodes HEVC may have no decoder for MPEG-4 Part 2 and only asking it finds out. A mode that fails is detected on an empty stdout before `stream_init` goes out, so the viewer sees one working stream and never an error. Client — Chromium ships VA-API off on Linux. It is enabled where a render node and a driver are present, then verified through `navigator.mediaCapabilities`: a no moves to the next GL backend on the next launch and an exhausted list drops the switches, so a renamed feature cannot pass for a feature that is on and `--ignore-gpu-blocklist` cannot survive on a machine it did not help. Feature lists now merge rather than overwrite — `appendSwitch` replaces the value, and a second caller would have silently cancelled the mDNS switch aiortc depends on. Packaging — the drivers are weak dependencies on all four formats, so a machine without a GPU installs exactly as before. `dpkg -i` and `rpm -ivh` ignore weak deps; `packaging/README.md` now says so. Windows needs no driver: the bundled ffmpeg already carries h264_qsv and h264_nvenc, and a re-pin that dropped them would cost every low-power Windows node its hardware encoding silently. AMD on Windows (AMF) and macOS (VideoToolbox) are named gaps, not oversights: neither could be tried anywhere in this project, and both re-encode in software as before. Co-Authored-By: Claude Opus 5 --- packaging/README.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) (limited to 'packaging/README.md') diff --git a/packaging/README.md b/packaging/README.md index ff65488..b65d0ed 100644 --- a/packaging/README.md +++ b/packaging/README.md @@ -42,6 +42,36 @@ sudo rpm -ivh meshbay-hub-*.rpm meshbay-node-*.rpm sudo rpm -ivh meshbay-client-*.rpm ``` +### Hardware video acceleration is a weak dependency + +Both the node and the client use the GPU for video where one works — the node to +re-encode a browser-hostile codec (`hwaccel.py`: VA-API on Linux, Quick Sync or +NVENC on Windows), the client to decode H.264 (`main.js`; only on Linux, since +Chromium already decodes in hardware on Windows and macOS). Neither requires it, +and both establish it by measurement rather than by assuming the packaged driver +is present and functional, so a machine without a GPU installs and runs exactly +as before. + +Only Linux needs packaged drivers — on Windows the bundled ffmpeg carries its +own encoders and Chromium uses the OS's decoder. The drivers are therefore +`Recommends` (`va-driver-all` on Debian/Ubuntu; +`libva`, `intel-media-driver`, `mesa-va-drivers` on Fedora), which matters for +how the packages are installed: **`dpkg -i` and `rpm -ivh` both ignore weak +dependencies; `apt` and `dnf` install them.** On a low-power machine — an Intel +mini-PC serving and watching video is the case this exists for — use the +resolver, so the drivers come too: + +```bash +sudo apt install ./meshbay-common_*.deb ./meshbay-node_*.deb ./meshbay-client_*.deb +sudo dnf install ./meshbay-common-*.rpm ./meshbay-node-*.rpm ./meshbay-client-*.rpm +``` + +Nothing has to be enabled afterwards and there are no flags to set by hand. The +node logs which encoder it found at the first stream (`hwaccel:`), and the +client records what it measured in its own `config.json` — the file that +already remembers the hub address — under `videoDecodeProbe`, and +`videoAcceleration: "off"` in that same file turns it back off. + ## Architecture meshbay-common owns the shared Python virtual environment at -- cgit v1.2.3