[PR #5019] [CLOSED] Change the transcode bitrate scaler GetVideoBitrateParamValue #10369

New Issue

OVERLORD · 2026-02-07T06:19:05+03:00

OVERLORD commented

2026-02-07 06:19:05 +03:00

📋 Pull Request Information

Original PR: https://github.com/jellyfin/jellyfin/pull/5019
Author: @hawken93
Created: 1/13/2021
Status: ❌ Closed

Base: master ← Head: bitrates

📝 Commits (1)

f7d2891 Change the transcode bitrate scaler GetVideoBitrateParamValue to be more logical

📊 Changes

1 file changed (+13 additions, -25 deletions)

View changed files

📝 MediaBrowser.Controller/MediaEncoding/EncodingHelper.cs (+13 -25)

📄 Description

I was annoyed that I got a much worse looking transcode than my source file.

I think the misconception from Emby all along has been that there's an equivalency between the source bitrate and the transcode bitrate, that the transcoded bitrate should be less or equal to the original one.

However, the original encoding has often been done with very nicely tweaked settings and a really slow encoding preset. The transcode will probably not look anywhere near as good as the original for the same bitrate.

That's why I want to extend the code a bit to add 1.5x headroom to all video streams, alongside the tweaks that add 2-4x bitrate to low bitrate video files.

While I was looking at it, I spotted logic errors that could cause between 4-10x bitrate for 500k - 3Mbit files, so I've changed the code a bit to make it more humanly understandable.

Arguably for h264, but I don't know for the other codecs, there's already a crf setting applied that will cause a sane bitrate limit for the transcoder. This means that if we just took the client setting (60Mbit or whatever) then the crf will become the deciding factor, so maybe we don't need to limit the bitrate based on the input. Table is open for discussions I guess.

There has been a long time since last I messed with this, so I think it should be tested for regressions no matter how safe the code changes look to my eyes..

Changes

Changes to GetVideoBitrateParamValue in MediaBrowser.Controller/MediaEncoding/EncodingHelper.cs

Issues
I bet there are some issues complaining about blocking artifacts and whatnot caused by bitrate starvation.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/jellyfin/jellyfin/pull/5019 **Author:** [@hawken93](https://github.com/hawken93) **Created:** 1/13/2021 **Status:** ❌ Closed **Base:** `master` ← **Head:** `bitrates` --- ### 📝 Commits (1) - [`f7d2891`](https://github.com/jellyfin/jellyfin/commit/f7d28918f844f927fd9e3c73057b65d8b0e3df26) Change the transcode bitrate scaler GetVideoBitrateParamValue to be more logical ### 📊 Changes **1 file changed** (+13 additions, -25 deletions) <details> <summary>View changed files</summary> 📝 `MediaBrowser.Controller/MediaEncoding/EncodingHelper.cs` (+13 -25) </details> ### 📄 Description I was annoyed that I got a much worse looking transcode than my source file. I think the misconception from Emby all along has been that there's an equivalency between the source bitrate and the transcode bitrate, that the transcoded bitrate should be less or equal to the original one. However, the original encoding has often been done with very nicely tweaked settings and a really slow encoding preset. The transcode will probably not look anywhere near as good as the original for the same bitrate. That's why I want to extend the code a bit to add 1.5x headroom to all video streams, alongside the tweaks that add 2-4x bitrate to low bitrate video files. While I was looking at it, I spotted logic errors that could cause between 4-10x bitrate for 500k - 3Mbit files, so I've changed the code a bit to make it more humanly understandable. Arguably for h264, but I don't know for the other codecs, there's already a crf setting applied that will cause a sane bitrate limit for the transcoder. This means that if we just took the client setting (60Mbit or whatever) then the crf will become the deciding factor, so maybe we don't need to limit the bitrate based on the input. Table is open for discussions I guess. There has been a long time since last I messed with this, so I think it should be tested for regressions no matter how safe the code changes look to my eyes.. **Changes** * Changes to GetVideoBitrateParamValue in MediaBrowser.Controller/MediaEncoding/EncodingHelper.cs **Issues** I bet there are some issues complaining about blocking artifacts and whatnot caused by bitrate starvation. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

OVERLORD added the pull-request label 2026-02-07 06:19:05 +03:00

OVERLORD closed this issue

2026-02-07 06:19:06 +03:00

Sign in to join this conversation.

Branches Tags

master

renovate/major-skiasharp-monorepo

renovate/sharpcompress-0.x

renovate/svg.skia-5.x

renovate/ghcr.io-devcontainers-features-docker-in-docker-4.x

release-10.11.z

standards-fix

release-10.9.z

openapi-cache

release-10.10.z

explicit-load

explicit-load-v2

feature/entity-framework

only-count-folder-item

fix/ci-workflow-refactor

release-10.8.z

release-10.7.z

EraYaN-add-management-interface

release-10.6.z

release-10.5.z

release-10.4.z

release-10.3.z

release-10.2.z

release-10.1.0

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/jellyfin#10369