Add audio remux to UniversalAudioController #11399
Draft
+90
−5
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gnattu
changed the title
|
This pull request has merge conflicts. Please resolve the conflicts so the PR can be successfully reviewed and merged. |
jellyfin-bot
added
the
merge conflict
Signed-off-by: gnattu <gnattuoc@me.com>
This will improve flexibility due to overcome the complex compatibility situation of HLS Signed-off-by: gnattu <gnattuoc@me.com>
The SupportsDirectStream is a little bit misleading as it actually means "Supports Direct Play" Signed-off-by: gnattu <gnattuoc@me.com>
jellyfin-bot
removed
the
merge conflict
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.