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:
parent
cfd4666bb2
commit
afd5856d0d
4 changed files with 126 additions and 4 deletions
24
CHANGELOG.md
24
CHANGELOG.md
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue