Set AudioCodec when building stream
Original-merge: a165883999
Merged-by: nielsvanvelzen <nielsvanvelzen@users.noreply.github.com>
Backported-by: Joshua M. Boniface <joshua@boniface.me>
Previously, we predicted whether the subtitle should be burned in with transcode reasons, but that was not accurate because the actual transcoding codec is only determined after the client has requested the stream. This pass through the option to the `DynamicHlsController` to handle the subtitle burn-in during the actual transcoding process. Now the client should be responsible to conditionally load the subtitle when this option is enabled.
Using the first profile's reason is somewhat arbitrary, as many clients' first profile may not be the most compatible one. For instance, browsers often set WebM as the first profile, which doesn’t support common codecs like H.264 and AAC by design. This causes `VideoCodecNotSupported` and `AudioCodecNotSupported` to be returned, even if the browser supports those codecs. Only use those reasons when all profiles indicate that the codec is not supported.
Signed-off-by: gnattu <gnattuoc@me.com>
Currently, when specifying codec profiles, the client can only specify profiles applied to direct containers, with no way to apply a profile specifically to HLS or a specific HLS container. This limitation is not suitable for more complex client codec support scenarios.
To address this, a SubContainer field is added to CodecProfile. The client can now specify the main container as "hls" to apply the profile exclusively to HLS streams. Additionally, the SubContainer field allows the profile to be applied to a specific HLS container.
Currently, this is only used in StreamBuilder for HLS streams. Further changes may be required to extend its usage.
Signed-off-by: gnattu <gnattuoc@me.com>
Bond-009
gnattu
Jellyfin Release Bot
joshjryan
Tim Eisele
gnattu
Niels van Velzen
Cody Robibero
Nyanmisaka
Shadowghost
Dmitry Lyzo
Dmitry Lyzo
JPVenson
llutic
Stepan Goremykin
theMasterpc