From 0e8318a536bc5c2a43142c83addb80a114a4b48f Mon Sep 17 00:00:00 2001 From: Jason Lu Date: Mon, 25 May 2026 03:56:55 -0700 Subject: [PATCH 1/2] fix(macos): drop max_ref_frames=1 for h264_videotoolbox MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit VideoToolbox on Apple Silicon produces all-IDR output when ReferenceBufferCount=1 is set for H.264 — every frame becomes a keyframe, P-frames are never produced, and bandwidth inflates roughly 3x while frame drops become severe. HEVC and AV1 on the same hardware are unaffected by this quirk and continue to honor max_ref_frames=1 correctly for reference-frame invalidation. Remove the option from h264_videotoolbox's common-options block only. HEVC and AV1 retain max_ref_frames=1 as before. Tracks LizardByte/Sunshine#5013. Diagnosis and original fix from the Lumen fork (github.com/trollzem/Lumen). --- src/video.cpp | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/video.cpp b/src/video.cpp index 00af66c3a69..e4561e780da 100644 --- a/src/video.cpp +++ b/src/video.cpp @@ -1134,12 +1134,16 @@ namespace video { }, { // Common options + // Note: max_ref_frames is intentionally omitted for H.264 because + // VideoToolbox on Apple Silicon produces all-IDR output when + // ReferenceBufferCount=1 is set for H.264, causing massive bandwidth + // inflation (~3x) and frame drops. HEVC and AV1 are unaffected and + // retain max_ref_frames=1. See LizardByte/Sunshine#5013. { {"allow_sw"s, &config::video.vt.vt_allow_sw}, {"require_sw"s, &config::video.vt.vt_require_sw}, {"realtime"s, &config::video.vt.vt_realtime}, {"prio_speed"s, 1}, - {"max_ref_frames"s, 1}, }, {}, // SDR-specific options {}, // HDR-specific options From 5620cd6a02ac16e66f2c9e5349701d5e39ce36ce Mon Sep 17 00:00:00 2001 From: Jason Lu Date: Wed, 27 May 2026 01:56:08 -0700 Subject: [PATCH 2/2] videotoolbox(h264): enable PARALLEL_ENCODING capability flag Per andygrundman + ReenigneArcher review on the original PR thread: > @andygrundman: "I can reproduce this bug and this is the right fix. > @ReenigneArcher can you also enable PARALLEL_ENCODING for all VT > encoders?" > > @ReenigneArcher: "@Nottlespike could you add @andygrundman's > suggestion to this PR please?" VideoToolbox encoders on macOS support multiple concurrent compression sessions (the kernel media engine schedules them), so the PARALLEL_ENCODING capability flag is correct to advertise. Sunshine uses this flag to decide whether the probe path may concurrently attempt multiple format/profile combinations against the same encoder. The flag lives on the encoder_t struct itself, not on per-codec options, so this single change covers all VT codecs the encoder registers (h264, hevc, and prores when present via the experimental opt-in in a separate PR). --- src/video.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/video.cpp b/src/video.cpp index e4561e780da..f2281ce841a 100644 --- a/src/video.cpp +++ b/src/video.cpp @@ -1155,7 +1155,7 @@ namespace video { }, "h264_videotoolbox"s, }, - DEFAULT + PARALLEL_ENCODING }; #endif