feat: use vpp_qsv hardware padding when available - #1
Closed
M-Pepper wants to merge 2 commits into
Closed
Conversation
QSV padding currently falls back to the software pad filter, which forces an hwdownload/hwupload round-trip per frame. Measured on an Intel Arc Pro B50 (640x480 4:3 -> 1440x1080 padded to 1920x1080, h264), that chain runs at 212 fps / 5.2s CPU versus 563 fps / 1.3s CPU for a hardware pad — parity with pad_vaapi, and essentially free relative to plain scaling. ffmpeg's vpp_qsv only gained pad_w/pad_h/pad_x/pad_y/pad_color in patched builds (submission to ffmpeg-devel pending), so plain filter presence cannot gate this. FfmpegInfo now probes AVOptions for selected filters via `ffmpeg -h filter=NAME` (currently just vpp_qsv), and the QSV best_filter substitutes PadQsv only when the pad_w option is advertised; otherwise behaviour is unchanged and the software pad chain is used. Co-Authored-By: Claude Fable 5 <[email protected]>
Chaining two vpp_qsv instances (scale then pad) drops the final frame at EOF on real hardware (measured on Intel B50: 1439/1440 packets). This reproduces with two plain vpp_qsv scales on stock ffmpeg, so it is a pre-existing ffmpeg flush quirk we must avoid triggering. A single combined instance delivers every frame and uses one VPP session. PadQsv gains an optional fused ScaleQsv; the optimize() pass folds a ScaleQsv into an immediately-following PadQsv (mirroring the existing CUDA fusion), emitting one vpp_qsv=w=..:h=..:pad_w=..:pad_h=..:pad_x=-1:pad_y=-1:pad_color=black. Pad-only chains, scale-only chains, and the software fallback are unchanged. The pad_w capability gate still governs the combined form. Co-Authored-By: Claude Fable 5 <[email protected]>
M-Pepper
force-pushed
the
qsv-hardware-pad
branch
from
July 30, 2026 18:14
ceb8888 to
20a4d05
Compare
Owner
Author
|
Superseded by the upstream PR: ErsatzTV#182 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two commits:
feat: use vpp_qsv hardware padding when available —
FfmpegInfogains per-filter option probing (
ffmpeg -h filter=vpp_qsv), and theQSV
best_filtersubstitutes a hardwarePadQsvop for the softwarepad when the binary's
vpp_qsvhaspad_w. On stock ffmpeg the probefinds nothing and the existing software pad chain is emitted unchanged
— no behavior change without a patched binary (see companion
ErsatzTV-ffmpeg PR; the patches are also on ffmpeg-devel upstream).
perf: fuse qsv scale+pad into a single vpp_qsv instance — measured
on hardware: two chained
vpp_qsvinstances drop the final frame atEOF (1439/1440; reproducible with two plain scales on stock ffmpeg), a
single combined instance does not. The fusion pass follows the existing
CUDA scale/format fusion precedent in
FilterChain::optimize().Emitted chain for the canonical 4:3→16:9 case:
Validated end-to-end with the real
ersatztv-channelworker on anIntel Arc Pro B50: patched-ffmpeg arm emits the fused chain with no
hwdownload and produces true-black 1920x1080 HLS segments
(Y/U/V = 16/128/128); stock-ffmpeg arm falls back to the software pad
and works. Benchmarks: GPU pad at parity with pad_vaapi (563 fps) vs
212 fps for the hwdownload/pad/hwupload chain. Running in production
against live channels since 2026-07-30.
Known limitation (pre-existing, unchanged): anamorphic sources use a
separate SAR pre-scale instance ahead of the fused scale+pad, so they
still emit two chained instances and keep the pre-existing EOF
last-frame behavior.
Companion PRs: M-Pepper/ErsatzTV-ffmpeg#1 (carries the ffmpeg patches),
M-Pepper/legacy#1 (same feature for the C# pipeline).