[PR #12837] [MERGED] Infer more audio codec from containers #13390

New Issue

OVERLORD · 2026-02-07T07:12:07+03:00

OVERLORD commented

2026-02-07 07:12:07 +03:00

📋 Pull Request Information

Original PR: https://github.com/jellyfin/jellyfin/pull/12837
Author: @gnattu
Created: 10/17/2024
Status: ✅ Merged
Merged: 10/19/2024
Merged by: @crobibero

Base: master ← Head: infer-more-codec

📝 Commits (1)

fa09e07 Infer more audio codec from containers

📊 Changes

1 file changed (+9 additions, -37 deletions)

View changed files

📝 MediaBrowser.Controller/MediaEncoding/EncodingHelper.cs (+9 -37)

📄 Description

This is mainly for some broken legacy clients that will unlikely to receive proper fix for audio transcoding profile and migrate to our new universal audio controller anytime soon. These legacy clients used an outdated Emby-era audio transcoding pipeline, where the client neither explicitly specifies the desired transcoding formats nor properly indicates the supported audio codecs in its request. Instead, they rely on just providing a container name in the request URL, hoping the server can guess the correct audio codec. However, this guessing is often inaccurate as the container-to-codec mapping has been hard-coded and outdated for six years. When the server cannot guess it will just return "copy" which will obviously fail because the client is requesting transcoding. This PR makes the infer logic more robust to only infer from containers that does not have the same name as the audio codec, and pick the "should be compatible" codec for the container. This may still fail in edge cases if the client is weird enough, but should cover most use cases.

Please note that some clients (like JMP) always requests the container same as the source audio (like from flac to flac) which might make the transcoding behavior weird, this has to be fixed on the client side.

Changes

Pick the in-theory compatible audio codec for requested container
If the container is not empty, default to just return the container name as codec

Issues

Fixes #12822

_{🔄 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/12837 **Author:** [@gnattu](https://github.com/gnattu) **Created:** 10/17/2024 **Status:** ✅ Merged **Merged:** 10/19/2024 **Merged by:** [@crobibero](https://github.com/crobibero) **Base:** `master` ← **Head:** `infer-more-codec` --- ### 📝 Commits (1) - [`fa09e07`](https://github.com/jellyfin/jellyfin/commit/fa09e07017dcf55aa09029997216e0c854d797d5) Infer more audio codec from containers ### 📊 Changes **1 file changed** (+9 additions, -37 deletions) <details> <summary>View changed files</summary> 📝 `MediaBrowser.Controller/MediaEncoding/EncodingHelper.cs` (+9 -37) </details> ### 📄 Description This is mainly for some broken legacy clients that will unlikely to receive proper fix for audio transcoding profile and migrate to our new universal audio controller anytime soon. These legacy clients used an outdated Emby-era audio transcoding pipeline, where the client neither explicitly specifies the desired transcoding formats nor properly indicates the supported audio codecs in its request. Instead, they rely on just providing a container name in the request URL, hoping the server can guess the correct audio codec. However, this guessing is often inaccurate as the container-to-codec mapping has been hard-coded and outdated for six years. When the server cannot guess it will just return "copy" which will obviously fail because the client is requesting transcoding. This PR makes the infer logic more robust to only infer from containers that does not have the same name as the audio codec, and pick the "should be compatible" codec for the container. This may still fail in edge cases if the client is weird enough, but should cover most use cases. Please note that some clients (like JMP) always requests the container same as the source audio (like from flac to flac) which might make the transcoding behavior weird, this has to be fixed on the client side.  **Changes**  - Pick the in-theory compatible audio codec for requested container - If the container is not empty, default to just return the container name as codec **Issues**  Fixes #12822 --- <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 07:12:07 +03:00

OVERLORD closed this issue

2026-02-07 07:12:08 +03:00

OVERLORD referenced this issue

2026-02-07 07:15:01 +03:00

[PR #13390] [MERGED] Catch IOExceptions for GetFileSystemMetadata #13554

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#13390