1 files changed, 30 insertions, 0 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