Server Version#: 1.32.5.7349
Player Version#: 5.67.2
Subtitle format: SRT
So this has not been much of a problem until recently due to my library consisting of 1080p videos. But now that I am starting to switch over to 4K UHD content its becoming apparent that subtitles are basically unusable due to single core of a CPU not being able to keep up.
I am using i5-8500k (6 core CPU) with iGPU (quicksync). HW transcodes work great for 4K UHD content until I turn on subtitles, then video buffers every few minutes and CPU usage is through the roof on one core.
Question: Is there some sort of limitation that prevents GPU from being used for the burn in? If its subtitle format incompatibility, then we have the tools to convert existing subtitles pretty much into any format in matter of seconds via ffmpeg (for me about 2 seconds to convert ASS to SRT for 2 hour movie via ffmpeg).
Question 2: If there is some sort of limitation that prevents us from using GPU, then is it possible to make it a multi threaded process? Can the process be optimized further? For example resizing to 1080p via HW, then burn in on top of that? CPU seems to be able to keep up with 1080p burn in.
Im not sure if I am alone, but I almost always watch everything with subtitles and as of now unfortunately I cant do that with any 4k content.
Pretty much, Unless the player can accept the subtitles AS-IS, PMS and playback suffer. The NAS boxes are brutalized by subtitle burning.
Text-based ASS & SSA should not be so hard for PMS to convert because, as you pointed out, it takes a few seconds manually.
This is on the To-Do list now.
The most painfully obvious subtitles are the image-based ones (PGS, VOBSUB, and DVDRIP)
These have always been a problem.
I recently found documentation which shows how to do image subtitle burning (PGS, VOBSUB, DVDRIP) in the hardware. It looks easy but turning out to not be as easy as it seems.
Between all the , I’ll get there. There is hope. No promises yet but hope.
Left alone long enough and I’ll get it done sooner ( “left alone?” hahahahaha)
As for making subtitle processing mult-threaded, The answer is regrettably no.
Subtitles must be burned into each video frame as they come out of the HW decode stage but before HW encode (to send out)
Thanks for the detailed explanation and giving hope for better subtitle support in the future (it will be necessary as 4K eventually will be the norm and CPU cores while getting a bit faster are having most of their gains in multi threading instead).
Any chance for interim solution of like how I mentioned transcoding video to 1080p, then having burn in on top of that, that way frames are much smaller in size. At least 4K content will be viewable (even if at loss to quality, which already happens anyways due to transcoding in the first place). Even if this requires 2 transcodes, firs to 1080p then to burn in.
Also what about forcing subtitles to be sent to client anyways? I seems like Plex sometimes does not identify capabilities correctly. On my LG TV if I set Plex to “Never burn in” it shows ASS subtitles no problem. If I leave it on Auto it tries to burn them in.
Which is a work around, but problem is that if set to Never, it wont burn in subtitles that TV actually cant support… like you said, the image formats.
We watch a lot of foreign language content in my household and my wife at this point basically refuses to use Plex because of the constant buffering this causes.
Please, please, please prioritize fixing this issue and restore the good name of Plex in my home
, I’ll get there. There is hope. No promises yet but hope.
