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
The QSV pipeline previously always padded in software, forcing a
hwdownload/pad/hwupload round-trip. ffmpeg's vpp_qsv filter is gaining
pad_w/pad_h/pad_x/pad_y/pad_color options, so when the ffmpeg binary
exposes them we can pad on the GPU instead, mirroring the existing
pad_vaapi hardware path.
A new capability probe runs `ffmpeg -h filter=vpp_qsv` and parses the
available AVOption names, surfaced as IFFmpegCapabilities.HasFilterOption.
QsvPipelineBuilder.SetPad now emits PadQsvFilter (vpp_qsv=pad_w=..:pad_h=..
:pad_x=-1:pad_y=-1:pad_color=black) when vpp_qsv advertises pad_w, and
keeps the software PadFilter fallback for HDR tonemap, forced software
pad mode, and stock ffmpeg builds without the pad options. The gate is
what makes this safe to upstream, since stock ffmpeg has no vpp_qsv pad
options yet.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* add new fields to database
* update editor
* audio and video normalization settings appear to work
* implement optional color normalization
* fix transcoding tests
* update changelog
* fix validation in new form layout
* pin mediatr to last oss version
* update dependencies
* cleanup code in core
* cleanup code in ffmpeg
* cleanup code in infra
* cleanup code in scanner
* cleanup code in application
* cleanup main code
* cleanup test code
* solution-wide code cleanup
* optionally include progress bar in generated song video
* update progress bar size/location
* move everything up 10% when song progress is enabled
* add watermark border to song progress bar
* always show accurate progress bar
* lower progress bar to 90% alpha
* update changelog
* use noautoscale with vaapi encoder
* only use one input file for vaapi with radeonsi driver
* fix vaapi 8-bit to 10-bit
* fix nvidia subtitle scaling
* optimize nvidia subtitle scaling
* fix test pgs subtitle
McKenzie Pepper
Jason Dove
Jason Dove