From f115fa6cbc1d428e39a9569ed3a9540fbc58d1ae Mon Sep 17 00:00:00 2001 From: Markus Fritsche Date: Mon, 4 May 2026 10:19:14 +0000 Subject: [PATCH] Phase 0 deliverable #3 (Firefox): headless-rig finding MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Firefox 150.0.1 + media.ffmpeg.vaapi.enabled=true + LIBVA_DRIVER_NAME= v4l2_request, executed under Xvfb on ohm. Result: inconclusive at the boolean-correctness level. RDD process dlopens libva.so.2 + libva-drm.so.2 + libva-x11.so.2 for capability probe then immediately closes them; never reaches vaInitialize, never opens /dev/dri/renderD128, never reaches v4l2_request_drv_video.so. Falls back to software H.264 in RDD via FFmpeg-OS-library PDM (Broadcast support from 'RDD', support=H264 SWDEC). Root cause: Xvfb provides software framebuffer with no DRI/DRM render-node integration. Firefox's gfx-environment platform-fitness check rejects VAAPI before adding it to the RDD PDM order list. Not a libva-side or driver-side fault — mpv --hwdec=vaapi-copy in the same headless rig DID engage end-to-end (per phase0_evidence/2026-05-04/findings.md). Definitive Firefox verdict requires retesting inside a live Plasma session — deferred to live-session run (next commit). Also: Phase 0 deliverable #2 (Step 1 reconciliation into fork master) was completed and pushed to marfrit/libva-v4l2-request-fourier between this and the prior Phase 0 commit; status table updated. Co-Authored-By: Claude Opus 4.7 (1M context) --- .../2026-05-04-firefox/findings.md | 124 ++ .../firefox.log.child-1.moz_log | 0 .../firefox.log.child-2.moz_log | 1933 +++++++++++++++++ .../2026-05-04-firefox/firefox.log.moz_log | 11 + .../2026-05-04-firefox/firefox_stderr | 95 + .../2026-05-04-firefox/profile_user.js | 49 + .../2026-05-04-firefox/strace_content_143725 | 553 +++++ .../2026-05-04-firefox/strace_parent_143578 | 1265 +++++++++++ .../2026-05-04-firefox/strace_rdd_143696 | 184 ++ .../2026-05-04-firefox/strace_utility_143764 | 512 +++++ phase0_evidence/2026-05-04-firefox/test.html | 15 + phase0_findings.md | 12 +- 12 files changed, 4752 insertions(+), 1 deletion(-) create mode 100644 phase0_evidence/2026-05-04-firefox/findings.md create mode 100644 phase0_evidence/2026-05-04-firefox/firefox.log.child-1.moz_log create mode 100644 phase0_evidence/2026-05-04-firefox/firefox.log.child-2.moz_log create mode 100644 phase0_evidence/2026-05-04-firefox/firefox.log.moz_log create mode 100644 phase0_evidence/2026-05-04-firefox/firefox_stderr create mode 100644 phase0_evidence/2026-05-04-firefox/profile_user.js create mode 100644 phase0_evidence/2026-05-04-firefox/strace_content_143725 create mode 100644 phase0_evidence/2026-05-04-firefox/strace_parent_143578 create mode 100644 phase0_evidence/2026-05-04-firefox/strace_rdd_143696 create mode 100644 phase0_evidence/2026-05-04-firefox/strace_utility_143764 create mode 100644 phase0_evidence/2026-05-04-firefox/test.html diff --git a/phase0_evidence/2026-05-04-firefox/findings.md b/phase0_evidence/2026-05-04-firefox/findings.md new file mode 100644 index 0000000..aac2a3b --- /dev/null +++ b/phase0_evidence/2026-05-04-firefox/findings.md @@ -0,0 +1,124 @@ +# Phase 0 deliverable #3 — Firefox VAAPI engagement test (2026-05-04) + +In-session test of stock Firefox 150.0.1 with `media.ffmpeg.vaapi.enabled=true` + `LIBVA_DRIVER_NAME=v4l2_request` env. Headless rig (Xvfb under SSH). + +## Verdict + +**Inconclusive at the boolean-correctness level under this rig.** Firefox loads our libva backend for a capability probe but does not engage it for the actual H.264 decode — falls back to software via FFmpeg in the RDD process. The decision to skip VAAPI happens **at Firefox's gfx-environment gating layer**, before VAAPI device init is attempted. **Likely cause: Xvfb provides software framebuffer with no DRI/DRM render-node integration, which Firefox requires for VAAPI surface allocation.** Not a libva-side or driver-side fault. + +A definitive Firefox verdict requires retesting inside a real Plasma/X session with live DRM access. That's a Phase 7 verification task once a session is live. + +## What was actually run + +Firefox 150.0.1, profile at `/tmp/firefox-vaapi-test/profile/` (preserved as `profile_user.js` here), with these prefs on top of stock: + +- `media.ffmpeg.vaapi.enabled = true` +- `media.ffvpx.enabled = false` +- `media.hardware-video-decoding.force-enabled = true` +- `media.hardware-video-decoding.enabled = true` +- `media.av1.enabled = false` +- `gfx.x11-egl.force-enabled = true` +- `widget.dmabuf.force-enabled = true` +- `media.rdd-process.enabled = true` +- `media.rdd-ffvpx.enabled = false` +- `media.rdd-ffmpeg.enabled = true` +- `media.gpu-process-decoder = true` +- `logging.PlatformDecoderModule = 5`, `logging.MediaPDM = 5` + +Env on top of stock: + +- `MOZ_DISABLE_RDD_SANDBOX=1`, `MOZ_DISABLE_CONTENT_SANDBOX=1`, `MOZ_DISABLE_GMP_SANDBOX=1`, `MOZ_DISABLE_SOCKET_PROCESS_SANDBOX=1` (rule out sandbox interference) +- `LIBVA_DRIVER_NAME=v4l2_request` + `LIBVA_V4L2_REQUEST_VIDEO_PATH=/dev/video1` + `LIBVA_V4L2_REQUEST_MEDIA_PATH=/dev/media0` +- `LIBVA_MESSAGING_LEVEL=2` + +Run command: + +``` +xvfb-run -a -s "-screen 0 1280x720x24" -- \ + strace -ff -ttt -s 256 -o /tmp/firefox-vaapi-test/strace/ff \ + -e trace=ioctl,openat,close,clone,clone3,execve \ + firefox -profile /tmp/firefox-vaapi-test/profile -no-remote -new-instance \ + file:///tmp/firefox-vaapi-test/test.html +``` + +Test page autoplays `bbb_1080p30_h264.mp4` via `