mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-07-16 05:43:54 +03:00
[PR #11399] Add audio remux to UniversalAudioController #12883
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?
Original Pull Request: https://github.com/jellyfin/jellyfin/pull/11399
State: closed
Merged: Yes
Changes
This PR adds audio remuxing (copying audio into another container without transcoding) support to the UniversalAudioController, allowing the client to request the audio to be in a specific container. When remuxing with HLS, the HLS container's constraint applies, and it will fallback to transcoding when the original audio codec is not supported by the chosen HLS container. When remuxing with HTTP, this assumes that the client-provided container supports the audio codec. If it does not, ffmpeg would fail.
To workaround the complex codec+container support situation in HLS, an HLS container override feature has been added. The client can explicitly require a container+codec combination supported by HLS. For example,
ts|mp3andmp4|flac. When combinations like these are present, the HLS stream will use the container specified in this profile, ignoring the one set by theTranscodingContainerquery string. The most common use case for this mode is to force mp3 to be remuxed in mpegts container because most browsers do not support mp3 in mp4 container, although it is technically supported by HLS. When specifying such overrides, the client should be responsible to ensure the container and codec compatibility.This would allow clients with strict container requirements to playback certain audio codecs. For example, Opus on Safari can be played with HLS + fmp4.
This can also workarounds a lot of container related issues, as listed below in the issues section.
Issues
#11113 This one is due to the flac/mp3 container containing too little information, the client's estimation of the "ticks" might not be accurate enough. Allowing the client to force an HLS remuxing with fmp4 can mitigate this issue as the mp4 container has more information about the timing. Most browsers do not support mp3 in mp4 container, so probably need to force to remux into mpegts to workaround the timing issue for mp3.
#3731 This issue arises because the flac container has non-standard metadata tags, causing the client to refuse to play the file. This can be mitigated by falling back to HLS remuxing when direct play fails, or simply by forcing HLS remuxing anyway.