summaryrefslogtreecommitdiffstats
path: root/packages/meshbay-node/tests/test_stream_video_transcode.py
diff options
context:
space:
mode:
authorChristophe Besson <cbesson@gmail.com>2026-09-18 14:37:08 +0200
committerChristophe Besson <cbesson@gmail.com>2026-09-18 14:37:08 +0200
commitd22ce0ba5aebfff5ffaea97982472f876af5da22 (patch)
tree073b7ad96bc58aa834cd8f781d81915fdaa6e338 /packages/meshbay-node/tests/test_stream_video_transcode.py
parent0d56cd33b975afe7648dd6f6380a30a7b5230c90 (diff)
downloadmeshbay-d22ce0ba5aebfff5ffaea97982472f876af5da22.tar.gz
feat: decode and re-encode video on the GPU where there is one
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 <noreply@anthropic.com>
Diffstat (limited to 'packages/meshbay-node/tests/test_stream_video_transcode.py')
-rw-r--r--packages/meshbay-node/tests/test_stream_video_transcode.py48
1 files changed, 48 insertions, 0 deletions
diff --git a/packages/meshbay-node/tests/test_stream_video_transcode.py b/packages/meshbay-node/tests/test_stream_video_transcode.py
index b165af4..0fd12c6 100644
--- a/packages/meshbay-node/tests/test_stream_video_transcode.py
+++ b/packages/meshbay-node/tests/test_stream_video_transcode.py
@@ -35,6 +35,7 @@ from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey
from meshbay_common.crypto import generate_gek
from meshbay_common.webcrypto import chunk_key_aes, decrypt_chunk_aes
+from meshbay_node import hwaccel
from meshbay_node.indexer.group_index import GroupIndex
from meshbay_node.transport.webrtc_server import WebRTCPeerSession, _probe_video
@@ -271,3 +272,50 @@ async def test_the_operator_can_refuse_the_re_encode_and_says_so(tmp_path):
f"the refusal must point at the setting that caused it: {detail!r}")
assert not [m for m in session.sent if m.get("type") == "stream_init"], (
"a stream_init went out with no codec string the client could check")
+
+
+@needs_mp3
+async def test_a_hardware_encoder_that_does_not_work_costs_the_viewer_nothing(
+ tmp_path, monkeypatch):
+ """A VA-API mode that fails falls through to libx264 and the film plays.
+
+ This is the failure that cannot be prevented by probing: `hwaccel.py`
+ proves the *encoder* with a test encode at startup, and nothing proves the
+ GPU can decode a particular source until it is asked to — iHD has no
+ MPEG-4 Part 2 decoder at all, which is exactly the file used here.
+
+ The encoder is faked onto `/dev/null` rather than skipped for want of a
+ GPU, so this runs identically on a machine with one and on a machine
+ without: both hardware modes fail instantly, and what is tested is that
+ the viewer sees one working stream and not an error. The demotions are
+ checked too — a library of Xvid files must not pay for the first one's two
+ dead spawns again and again.
+ """
+ clip = tmp_path / "clip.avi"
+ _make_mpeg4_clip(clip)
+ gek = generate_gek()
+ session, file_id = _session(clip, gek)
+
+ hwaccel._reset_for_tests()
+
+ async def _broken_encoder():
+ vaapi = next(c for c in hwaccel.CANDIDATES if c.name == "vaapi")
+ return hwaccel.Encoder(candidate=vaapi, variant="standard", extra=(),
+ device="/dev/null")
+
+ monkeypatch.setattr(hwaccel, "encoder", _broken_encoder)
+ try:
+ await session._stream_video_inner({"file_id": file_id, "start": 0, "credits": 0})
+
+ assert not [m for m in session.sent if m.get("type") == "error"], (
+ "a hardware encoder that does not work must cost the viewer nothing")
+ remuxed = _reassemble(session.sent, gek, file_id)
+ out_path = tmp_path / "out.mp4"
+ out_path.write_bytes(remuxed)
+ assert _output_video_codec(out_path) == "h264", \
+ "the software fallback must still deliver a playable H264 stream"
+
+ assert ("mpeg4", hwaccel.HW) in hwaccel._demoted
+ assert ("mpeg4", hwaccel.HWENC) in hwaccel._demoted
+ finally:
+ hwaccel._reset_for_tests()