diff options
| author | scheilch <christian.scheil@icloud.com> | 2026-03-29 12:39:16 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2026-03-29 12:39:16 +0200 |
| commit | 5cfa466d8b0069e04c7d5c4e4f9b9a4bb7464034 (patch) | |
| tree | 6e1bc995d473927f4f220a019473d37c0207d6a8 /MediaBrowser.Controller/Extensions | |
| parent | 921a364bb0b94b54f7a3215accdb0bc5f51ef9e7 (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
