7 files changed, 62 insertions, 8 deletions
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
diff --git a/packaging/deb/meshbay-client/DEBIAN/control b/packaging/deb/meshbay-client/DEBIAN/control
index aeb5865..17711c8 100644
--- a/packaging/deb/meshbay-client/DEBIAN/control
+++ b/packaging/deb/meshbay-client/DEBIAN/control
@@ -7,7 +7,8 @@ Maintainer: MeshBay Team <devel@meshbay.org>
 Homepage: https://meshbay.org
 Depends: libgtk-3-0, libnotify4, libnss3, libxss1, libxtst6,
          libatspi2.0-0, libdrm2, libgbm1, libasound2
-Recommends: meshbay-node
+Recommends: meshbay-node, va-driver-all
+Suggests: vainfo
 Description: MeshBay — peer-to-peer file sharing, streaming and group chat
  Desktop client for MeshBay. Connects to MeshBay nodes over WebRTC for
  file sharing, video streaming, and group chat. Includes Chromecast and
diff --git a/packaging/deb/meshbay-node/DEBIAN/control b/packaging/deb/meshbay-node/DEBIAN/control
index 3eda3fa..eb19eb7 100644
--- a/packaging/deb/meshbay-node/DEBIAN/control
+++ b/packaging/deb/meshbay-node/DEBIAN/control
@@ -6,7 +6,7 @@ Architecture: all
 Maintainer: MeshBay Team <devel@meshbay.org>
 Homepage: https://meshbay.org
 Depends: meshbay-common (= __VERSION__)
-Recommends: ffmpeg
+Recommends: ffmpeg, va-driver-all
 Description: MeshBay Node — local file host, streaming server, and group daemon
  MeshBay Node indexes local directories and serves encrypted files to
  authenticated group members over WebRTC. Includes video streaming (fMP4
@@ -15,4 +15,6 @@ Description: MeshBay Node — local file host, streaming server, and group daemo
  .
  Installs node code into the shared venv at /opt/meshbay-common/venv/.
  Ships a default TMDB API token for the Videos app.
- Runs as a systemd user service.
+ Runs as a systemd user service. Re-encodes video on the GPU where one
+ works (VA-API), which is what makes streaming an HEVC film from a
+ low-power machine possible at all.
diff --git a/packaging/rpm/meshbay-client.spec b/packaging/rpm/meshbay-client.spec
index 867205f..0816741 100644
--- a/packaging/rpm/meshbay-client.spec
+++ b/packaging/rpm/meshbay-client.spec
@@ -17,6 +17,13 @@ Requires:       libdrm
 Requires:       mesa-libgbm
 Requires:       alsa-lib
 Recommends:     meshbay-node
+# Weak deps: an unresolvable one is skipped, so naming the drivers of both
+# families costs nothing and covers Fedora and RHEL alike. See hwaccel.py
+# (node) / main.js (client) — neither assumes any of this is installed.
+Recommends:     libva
+Recommends:     intel-media-driver
+Recommends:     mesa-va-drivers
+Suggests:       libva-utils
 
 %description
 Desktop client for MeshBay. Connects to MeshBay nodes over WebRTC for
diff --git a/packaging/rpm/meshbay-node.spec b/packaging/rpm/meshbay-node.spec
index 6ac13fb..1ba7f26 100644
--- a/packaging/rpm/meshbay-node.spec
+++ b/packaging/rpm/meshbay-node.spec
@@ -10,6 +10,12 @@ BuildArch:      noarch
 
 Requires:       meshbay-common = %{version}
 Recommends:     ffmpeg
+# Weak deps: an unresolvable one is skipped, so naming the drivers of both
+# families costs nothing and covers Fedora and RHEL alike. See hwaccel.py
+# (node) / main.js (client) — neither assumes any of this is installed.
+Recommends:     libva
+Recommends:     intel-media-driver
+Recommends:     mesa-va-drivers
 
 %description
 MeshBay Node indexes local directories and serves encrypted files to
diff --git a/packaging/win/README.md b/packaging/win/README.md
index b5ab1cd..0598193 100644
--- a/packaging/win/README.md
+++ b/packaging/win/README.md
@@ -98,8 +98,13 @@ That runs [`build-win.ps1`](build-win.ps1):
 **Bundled by default** — [`fetch-ffmpeg.ps1`](fetch-ffmpeg.ps1) downloads,
 checksum-verifies and stages it into `node-runtime/` on every build, ~161 MB.
 Not optional in practice: MeshBay transcodes browser-incompatible video to
-H.264 (`-c:v libx264`, a real encode, not remux), and no LGPL-only ffmpeg
-build includes an H.264 *encoder* — libx264 itself is GPL. Asking an end user
+H.264 (a real encode, not remux), and no LGPL-only ffmpeg build includes an
+H.264 *encoder* — libx264 itself is GPL. libx264 is also the floor rather
+than the only path: this build carries `h264_qsv` and `h264_nvenc` as well,
+which is what lets `hwaccel.py` move the encode onto an Intel or NVIDIA GPU
+on Windows without a second download. **A re-pin that dropped those would
+cost every low-power Windows node its hardware encoding, silently** — the
+node would simply go back to libx264. Asking an end user
 to separately run `winget install ffmpeg` was considered and rejected: it
 needs network access and `winget`/App Installer present at that exact moment,
 and its failure mode is silent — video just does not stream, with nothing
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