Allow external subtitle files (SRT, ASS, PGS, etc.) to be muxed into
MKV output containers when the device profile requests Embed delivery.
Previously, the IsExternal guard in GetSubtitleProfile excluded external
subtitles from Embed consideration entirely, forcing them to be served
as separate sidecar files even when the output container supports
embedding.
Changes:
- Extract CanConsiderEmbedSubtitle in StreamBuilder to allow external
subs through when transcoding to MKV
- Add external subtitle file as FFmpeg input (-i) for Embed delivery
- Map external embedded subs from the correct FFmpeg input index
- Fix external audio map index to account for the new subtitle input
- Extract NeedsExternalSubtitleMuxing in EncodingHelper to deduplicate
the external subtitle input check
Fixes#16403
* Add OriginalLanguage as option to PreferredAudioLanguage
* Support for multiple original languages
* Add original audio stream indicator
* Fetch OriginalLanguage from TMDB
* Adapt to EFCore refactor
* Fix PlayDefaultAudioTrack OriginalLanguage behavior
* Fix better PlayDefaultAudioTrack OriginalLanguage behavior
* Add comment to ItemFields
* Improved PlayDefaultAudioTrack behavior
* Add migration for original language
* Use sting.Equals for string comparisons
* Always set dto OriginalLanguage
* Remove OriginalLanguage from ItemFields
---------
Co-authored-by: Lampan-git <lampan-git@users.noreply.github.com>
* fix: cap GetVideoBitrateParamValue at 400 Mbps
The previous cap of int.MaxValue / 2 (~1073 Mbps) is far beyond any
realistic transcode target and allows encoder parameters derived from
it (e.g. -bufsize = bitrate * 4 for QSV) to grow to multi-gigabit
values, which is incorrect regardless of whether the encoder tolerates it.
400 Mbps is a safe upper bound for all current hardware encoders:
- Intel QSV H.264 peaks at ~300 Mbps (High 5.1 CPB = 168.75 Mbit)
- HEVC High Tier Level 5.x supports ~240 Mbps
- AV1 hardware encoders have no meaningful real-world constraint at
this level
The existing FallbackMaxStreamingBitrate mechanism (default 30 Mbps)
provides a similar guard but only when LiveStreamId is set, covering
M3U and HDHR sources. Plugin-provided streams and any source that
bypasses the LiveTV pipeline are not subject to it and can pass
unreasonably high values downstream. This cap closes that gap for
all encoder paths.
Suggested by @nyanmisaka in review of #16376.
* Update MediaBrowser.Controller/MediaEncoding/EncodingHelper.cs
---------
Co-authored-by: Bond-009 <bond.009@outlook.com>
Piotr Niełacny
Bond-009
Shadowghost
nyanmisaka
TheMelmacian
Erik W
JPVenson
Niels van Velzen
Gabriel Luci
dkanada
Seven Rats
gnattu
Tim Eisele
Joshua M. Boniface
theguymadmax
scheilch