aboutsummaryrefslogtreecommitdiff
path: root/MediaBrowser.Controller/Extensions
diff options
context:
space:
mode:
authorscheilch <christian.scheil@icloud.com>2026-03-29 12:39:16 +0200
committerGitHub <noreply@github.com>2026-03-29 12:39:16 +0200
commit5cfa466d8b0069e04c7d5c4e4f9b9a4bb7464034 (patch)
tree6e1bc995d473927f4f220a019473d37c0207d6a8 /MediaBrowser.Controller/Extensions
parent921a364bb0b94b54f7a3215accdb0bc5f51ef9e7 (diff)
fix: cap GetVideoBitrateParamValue at 400 Mbps (#16467)
* fix: cap GetVideoBitrateParamValue at 400 Mbps The previous cap of int.MaxValue / 2 (~1073 Mbps) is far beyond any realistic transcode target and allows encoder parameters derived from it (e.g. -bufsize = bitrate * 4 for QSV) to grow to multi-gigabit values, which is incorrect regardless of whether the encoder tolerates it. 400 Mbps is a safe upper bound for all current hardware encoders: - Intel QSV H.264 peaks at ~300 Mbps (High 5.1 CPB = 168.75 Mbit) - HEVC High Tier Level 5.x supports ~240 Mbps - AV1 hardware encoders have no meaningful real-world constraint at this level The existing FallbackMaxStreamingBitrate mechanism (default 30 Mbps) provides a similar guard but only when LiveStreamId is set, covering M3U and HDHR sources. Plugin-provided streams and any source that bypasses the LiveTV pipeline are not subject to it and can pass unreasonably high values downstream. This cap closes that gap for all encoder paths. Suggested by @nyanmisaka in review of #16376. * Update MediaBrowser.Controller/MediaEncoding/EncodingHelper.cs --------- Co-authored-by: Bond-009 <bond.009@outlook.com>
Diffstat (limited to 'MediaBrowser.Controller/Extensions')
0 files changed, 0 insertions, 0 deletions