mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-07-16 05:43:54 +03:00
[Issue]: Playback Stalls when Burning in Certain Subtitles on Large Files #5920
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?
Originally created by @Jacky161 on GitHub (Jun 3, 2024).
Please describe your bug
When playing back media with unsupported subtitle formats, the subtitles will typically need to be burned into the video during transcoding. Commonly, this issue occurs with Android devices that don't support ASS subtitles that are commonly used in anime. I am unsure if other subtitle formats are affected. When trying to playback large media that requires subtitle burn in, I found that Jellyfin will stall for an extremely long period of time, seemingly reading back the entire file from disk before transcoding begins. This occurs even after using the Subtitle Extract plugin to extract all subtitles from the video file as a scheduled task. It would make sense that the issue would occur if Subtitle Extract was not run but even after running, it does not appear to have affected anything.
A workaround for android at least is to enable "Allow SSA/ASS subtitles in direct play" which sidesteps the whole issue with transcoding and burning in. However this is not ideal as the subtitle styling does not work properly.
To test this issue, I used a brand new Debian 12 install with a competely clean Jellyfin install. The video file is on the local drive.
Reproduction Steps
Jellyfin Version
10.9.0
if other:
10.9.4
Environment
Jellyfin logs
FFmpeg logs
Please attach any browser or client logs here
No response
Please attach any screenshots here
Code of Conduct
@jellyfin-bot commented on GitHub (Jun 3, 2024):
Hi, it seems like your issue report has the following item(s) that need to be addressed:
This is an automated message, currently under testing. Please file an issue here if you encounter any problems.
@gnattu commented on GitHub (Jun 3, 2024):
You are using CPU and your CPU is not fast enough for such burn-in task.
@Jacky161 commented on GitHub (Jun 3, 2024):
That isn't the problem as I ran into this issue on my normal instance that has quick sync. I was simply using a testing environment with CPU transcoding to troubleshoot.
@Shadowghost commented on GitHub (Jun 3, 2024):
We can't debug an issue on QSV with logs from a CPU only setup...
This being slow and maybe too slow on a CPU only setup is to be expected.
@Jacky161 commented on GitHub (Jun 3, 2024):
I've provided logs from my quick sync setup. The issue is not with the speed of the actual transcoding once it is started. The issue is that the transcoding takes several minutes to get started in the first place with very high IO usage during this time period.
FFmpeg Logs
In particular, it hangs where it says "[Parsed_subtitles_2 @ 0x5605e6bd9640] Using font provider fontconfig". Eventually it moves past this point, prints essentially the same message "[Parsed_subtitles_2 @ 0x5605e6d56cc0] Using font provider fontconfig", hangs here for another long period of time before finally starting to playback. It's difficult to tell in the FFmpeg logs since there aren't timestamps but there are multi minute delays in between making it past these steps.
Jellyfin Logs:
@nyanmisaka commented on GitHub (Jun 3, 2024):
This is a limitation of FFmpeg itself. When reading embedded text-based subtitles, the entire video file must be read before transcoding can begin. To fix this, the entire subtitle implementation in FFmpeg must be rewritten.
@Jacky161 commented on GitHub (Jun 4, 2024):
I see. That does make sense for embedded subtitles but I figured that extracting subtitles beforehand (with Subtitle Extract plugin) would resolve this since the subtitle file would be ready to use on disk and not need to be reextracted. I decided to look into the issue a bit further with my very limited knowledge and found that if I hardcoded the path to my subtitle file on disk, playback would start immediately and the issue was resolved.
To test, I simply hardcoded this file with the path to the subtitles and built from source:
3738f87278/MediaBrowser.Controller/MediaEncoding/EncodingHelper.cs (L1511)This would change the path provided to FFmpeg as such: (from ffmpeg log)
to
Normally (from my limited knowledge), it seems that it provides FFmpeg the path to the video file itself to grab the subtitles from. Changing this to point to an already extracted subtitle file resolved the issue.
I believe the issue could be resolved if there was someway for Jellyfin to provide ffmpeg directly with preextracted subtitle files within the subtitles folder instead of having it extract the embedded version. It seems like this already occurs with the fonts as FFmpeg is pointed to a folder within the cache for those so hopefully something similar could be achieved with the subtitles itself. Apologies if any of this is incorrect or confusing since I'm just testing and playing around with things that I observed.
@JustinLex commented on GitHub (Jul 29, 2024):
Can confirm this issue is happening for me on QSV with 6-7GB files with embedded subs. Other media plays back fine, but starting transcoding on these files stalls for minutes before playback starts. Playback works fine when subtitles are disabled. Being able to play extracted subtitles seems to be needed for these files to playback properly.
@MeowTechOpenSource commented on GitHub (Aug 26, 2024):
I can confirm it happening on AMD system too (with hw accel). A 5-6 GB movie file with embedded ass subtitles take 1-2 minutes to load and sometimes throw the "source error" error on android client.
@rodrigocabraln commented on GitHub (Dec 24, 2025):
I'm currently having this problem in version 10.11.5 as well. In some tests, I got to Emby and it works perfectly; I don't know how they implemented it.