Add option to always burn in subtitles when transcoding

[GertSallaerts]

Changes
Adds support for toggling the alwaysBurnInSubtitleWhenTranscoding option that was introduced to Jellyfin in 10.10.

Issues
Fixes #4399

Notes
This is a first draft, partly to check whether or not you're amenable to adding this feature at all and partly to check if it's going in the right direction.

Things I know may need work:

• I have to double-check the whole burningSubs logic (PlaybackController and PlaybackControllerHelper) for different scenarios
• I was wondering if you could tell me whether or not the new playback code is far enough along for me to try adding it there as well of if it's something best left for later (or never).

[nielsvanvelzen]

Personally I dislike this feature because you'll lose all customization on subtitles when they are burned into the video. I'd rather look into what causes the subtitles to be out-of-sync. There's a possibility (although small) that it is already fixed in the master branch after #4455 was merged.
If we have a better understanding of what causes the sync issues and determine it is not (easily) fixable we can always look into the burning option again.

[GertSallaerts]

Personally I dislike this feature because you'll lose all customization on subtitles when they are burned into the video. I'd rather look into what causes the subtitles to be out-of-sync.

To quote my comment on the related issue here:

From what I understand, subtitle sync issues during transcoding are a problem that's not easy to solve and a new option was introduced in Jellyfin 10.10 to help out people who are affected. (jellyfin/jellyfin#2547 (comment), jellyfin/jellyfin#12430).

Subtitles often have synchronization issues after video transcoding. This option allows the client to opt-in to always burn in all subtitles, preventing out-of-sync subtitles at the cost of transcoding performance.

The option is already implemented in jellyfin-web where I tested it out and (for me at least) it solved the sync issues I was seeing when transcoding.

Now, I don't know much about Jellyfin's internals, I've been using it for a bit more than a year but this is the first time I'm exploring the code. But to me it sounded like this is an issue on the server that is unlikely to get solved in the short run which is why you/they are offering this workaround. I might be wrong about that, so I'll also tag @gnattu who may be able to explain this better than I can.

I do understand and appreciate your concerns about customization on subtitles, but I do think most users would prefer losing that over not being able to understand what's being said in their videos.

If a fix for these sync issues was on the horizon, I would also want to push that through over adding a workaround, but it doesn't look like that to me. As things stand, and if it is indeed a server issue, I'd even consider this PR to be adding a missing feature to improve feature parity.

I should probably have gotten involved earlier, reporting this at least, but I would be remiss not to add I've had this problem from the day I started using Jellyfin and have just been lucky that up until now my client and network have always been capable of direct playing anything I threw at it.

There's a possibility (although small) that it is already fixed in the master branch after #4455 was merged.

No, it didn't fix this (for me), I tested if the issue was still present on master before I started on this PR.

If we have a better understanding of what causes the sync issues and determine it is not (easily) fixable we can always look into the burning option again.

Maybe @gnattu will be able to shed some light on that but if there is anything I can do in regards to testing, do please let me know.

[gnattu]

It is indeed a problem that is hard to track down. Neither Emby nor Plex provided full solution to this yet. The transcoding is a very complex process and the time codes can change during that process, and sometimes it would be larger enough to make the original subtitles to look very off with the original time codes. You might even notice that the transcoded video can have a different video duration that is longer/shorter than the original one, and sometimes even the actual fps is slightly modified (like 29.97 being speeded up to 30). There are too many reasons that the time code might being altered and that is why I implemented that brute force hack as a workaround.

Is it bad? Yes. And the way it is implemented is also very hacky. Because we don't have a good API to determine the actual playback method before the playback has started (the one returns before the playback does not differ transcode and remux and both will be reported as remux), the is transcoding is detected after the playback has started using the api to check for playback stats, and then determine should the client load the subtitle or not to prevent double-subtitles.