The QSV pipeline downloaded every hardware frame to system memory before
setpts "always for setpts", then re-fed software frames to the qsv encoder.
Combined with commit 30280ae's GPU pad this was a net loss on Intel B50
(224 fps / 6.5s CPU vs. 242 fps / 5.6s CPU for the old download+CPU-pad path)
because the padded frame was downloaded only to be uploaded again by h264_qsv.
setpts and fps operate on timestamps only and accept hardware frames, and the
qsv encoder ingests hardware frames directly, so the download is now skipped
whenever nothing downstream needs system memory: hardware qsv encoder, no
watermark, no subtitle overlay or burn-in, no graphics engine, and no
follow-on colorspace conversion (which prepends its own hwdownload). Every
config that still needs software frames keeps the download in exactly the same
place as before. On B50 the full-GPU chain measures 503 fps / 1.8s CPU, 2.1x
the old download+CPU-pad baseline.
Because two chained vpp_qsv instances drop the final frame at EOF (1439/1440,
a pre-existing ffmpeg quirk reproducible with two plain scales on stock
ffmpeg), a hardware scale followed by a hardware pad is now emitted as one
vpp_qsv instance carrying both the scale and the pad_w/pad_h options.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0139ePZuiHJGo2g4PY2tQJ9Q
McKenzie Pepper
cdef25ffc2