feat(vaapi): hybrid CPU-scale + hwupload encode path (QW2, 0.9.14)

Closes QW2. Validated against the dev box's AMD Raphael iGPU
(/dev/dri/renderD128, radeonsi/mesa 25.2.8). The "proper" full-GPU
path via scale_vaapi triggers a known mesa 25 + Raphael bug
("Cannot allocate memory" per session start, encode still succeeds
but logs are spammy) — hybrid CPU scale → format=nv12 → hwupload
→ h264_vaapi encode delivers GPU surfaces to the encoder without
poking the broken scaler.

Three concrete changes in buildHLSFFmpegArgsAt:
  1. New `case "h264_vaapi"` adds `-vaapi_device /dev/dri/renderD128`.
     Multi-GPU hosts (this dev box has NVIDIA on renderD129 + AMD on
     renderD128) need it so the encoder doesn't bind to a non-VAAPI
     render node — without it the encoder fell back to NULL device
     in manual smoke testing.
  2. Filter chain branches on codec: VAAPI uses
     `scale=…,format=nv12,hwupload` while libx264 / NVENC / QSV
     keep the existing `scale=…,format=yuv420p,setparams=…` shape.
     The setparams color metadata block is dropped on VAAPI because
     VAAPI surfaces don't expose VUI fields and the encoder writes
     its own.
  3. Two new unit tests lock the argv shape so a future refactor
     doesn't accidentally merge the paths back together:
     TestBuildHLSFFmpegArgsVAAPI asserts the new flags + the
     ABSENCE of scale_vaapi; TestBuildHLSFFmpegArgsLibx264NoRegression
     verifies the software path keeps yuv420p + setparams + has
     none of the VAAPI extras.

Manual ffmpeg validation on the dev box:
  hybrid encode of 5 s 4K → 720p: 0.66 s wall, 472 % CPU, 268 KB
  output — no errors logged. scale_vaapi variant in comparison
  spammed "Cannot allocate memory" while emitting valid output.
This commit is contained in:
Deivid Soto 2026-05-27 15:45:55 +02:00
parent cfd4666bb2
commit afd5856d0d
4 changed files with 126 additions and 4 deletions

View file

@ -5,6 +5,30 @@ All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [0.9.14] - 2026-05-27
### Changed
- **VAAPI encode path now ships proper GPU surfaces**. Adds
`-vaapi_device /dev/dri/renderD128` so the encoder doesn't fall
back to a NULL device on multi-GPU hosts (the dev box that
validated this has an NVIDIA dGPU on renderD129 + an AMD iGPU on
renderD128 — without the explicit device the encoder picked the
wrong node). Filter chain switches to `format=nv12,hwupload`
(was `format=yuv420p`) so frames arrive at the encoder as VAAPI
surfaces. Color-metadata `setparams=` block is dropped on the
VAAPI path because VAAPI surfaces don't expose VUI fields the
same way libx264 does — the encoder records its own.
Intentionally avoids `scale_vaapi`: mesa 25 + AMD Raphael iGPU
emit "Cannot allocate memory" per session start, polluting logs
even though encode succeeds. CPU scale + hwupload is the safe
hybrid that works across all VAAPI-capable hosts.
- **Unit tests** lock the argv shape: TestBuildHLSFFmpegArgsVAAPI
asserts the new VAAPI flags + absence of scale_vaapi /
format=yuv420p; TestBuildHLSFFmpegArgsLibx264NoRegression
ensures the libx264 path keeps its `setparams` + `yuv420p` and
doesn't accidentally inherit the VAAPI shape.
## [0.9.13] - 2026-05-27
### Added