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/win/fetch-ffmpeg.ps1 | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) (limited to 'packaging/win/fetch-ffmpeg.ps1') diff --git a/packaging/win/fetch-ffmpeg.ps1 b/packaging/win/fetch-ffmpeg.ps1 index 5f6123d..6ffbc51 100644 --- a/packaging/win/fetch-ffmpeg.ps1 +++ b/packaging/win/fetch-ffmpeg.ps1 @@ -3,9 +3,12 @@ Download, verify and stage the ffmpeg/ffprobe MeshBay bundles by default. .DESCRIPTION - MeshBay transcodes browser-incompatible video to H.264 (webrtc_server.py, - `-c:v libx264`) -- a real encode, not just remux/probe -- so only a GPL - ffmpeg build works here; libx264 is GPL, no LGPL-only build includes it. + MeshBay transcodes browser-incompatible video to H.264 (webrtc_server.py) + -- a real encode, not just remux/probe -- so only a GPL ffmpeg build works + here; libx264 is GPL, no LGPL-only build includes it. The gpl-shared + preset also carries h264_qsv and h264_nvenc, which hwaccel.py uses to put + that encode on the GPU where there is one; a build without them still + works and is simply slower, on the machines that can least afford it. Asking an end user to separately install ffmpeg (`winget install ffmpeg`) is not viable for a non-technical install: it needs network access and winget/App Installer present at that exact moment, and fails silently -- cgit v1.2.3