mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-07-16 05:43:54 +03:00
[PR #12644] [MERGED] Better bitrate and resolution normalization #13303
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📋 Pull Request Information
Original PR: https://github.com/jellyfin/jellyfin/pull/12644
Author: @gnattu
Created: 9/14/2024
Status: ✅ Merged
Merged: 9/22/2024
Merged by: @crobibero
Base:
master← Head:tune-bitrate-res📝 Commits (3)
4e3a929Don't scale bitrate beyond 30Mbpsae697b3Normalize Resolution more reasonably15e46d9Fix HDR scaling📊 Changes
3 files changed (+50 additions, -35 deletions)
View changed files
📝
Jellyfin.Api/Helpers/StreamingHelpers.cs(+7 -1)📝
MediaBrowser.Controller/MediaEncoding/EncodingHelper.cs(+7 -1)📝
MediaBrowser.Model/Dlna/ResolutionNormalizer.cs(+36 -33)📄 Description
Previously we don't cap how much we want to scale the bitrate when transcoding to a less efficient codec like h264, resulting in extremely undesired high bitrate from high bitrate original videos, for example 80M AV1 will produce 120M H.264 file which overloads the server encoder, the client decoder and probably also the network. This set a scaling cap at 30Mbit, which means we don't scale up bitrate after 30M anymore, so that the bitrate will not be significantly larger than original if the original video has a high enough bitrate. For videos at such high bitrate the result is hardly noticeable (or not noticeable at all) with our current prefer speed encoding presets.
The previous resolution normalization is also outdated and not well-suited for modern advanced codecs and UHD videos. It is overly conservative with the use of high resolutions. This normalizes resolution while taking into account codec efficiency, frame rate, and dynamic range, providing in a more appropriate resolution config. All resolution configurations are now normalized based on the bitrate for H.264 in SDR at 30fps. The reference bitrate used to determine the resolution will be adjusted accordingly for codec, frame rate, and dynamic range (HDR reserved for future use, we are not doing HDR transcoding now). As a result, users will see higher resolutions more frequently when bitrate caps are applied.
The old logic of "using the previous configuration if the max bitrate is reached," inherited from Emby also didn't make much sense to me. I've changed it to "if the reference bitrate is below this configuration's max value, then use this configuration" which makes more sense for a "maxBitrate".
We probably also want to change the web texts based on this change as the resolution texts on web will now make almost no sense and even more wrong. In extreme condition now the text can say 720p 8Mbps on web and the video is streamed in 1440p which is a 2x resolution difference.
The new resolution config's max bitrate is taken from Apple's HLS document with modifications to fit our own scaling.
Changes
Issues
See recent post on forum: https://forum.jellyfin.org/t-solved-jellyfin-bitrate-is-way-to-high-on-firefox
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.