Indeed I was able to reproduce this on a i7 7700 and also on a i7 8700 when the server had to burn-in image-based subtitles. I was curious whether there is a solution to this problem and had a look at the command that is used for transcoding.
The following shows the video processing that is done after decoding with the gpu
Thus, the complete image processing is done by the CPU (which includes tonemapping).
Without subtitles the image processing is done with VAAPI and OpenCL:
I wanted to reproduce that with my local ffmpeg installation but I had problems with the reverse hwmap and gave up.
I had a look at the documentation of ffmpeg and found that there is a filter called opencl_overlay which can be used to hw accelerate image overlaying. I’m sure that this has been evaluated by Plex but I would like to know why this is not possible? Of course the subtitles have to be decoded by the cpu but why is it not possible to decode the subtitles and send it to the gpu, while the complete image processing is done by the gpu?
I wanted to add a me too on this thread. I am a relatively new owner of a DS920+ here and hit this issue tonight. VOB and PGS subtitles on a Roku Ultra completely ground to a halt.
A question, in DSM 7.0 exactly how do you locate the preferences.xml file location? In File station on the syno NAS I don’t see any of these application folders, just my personal content folders. Again I am new to this NAS so specific instructions to find the folder would be highly appreciated.
Also, I saw in some other posts that users recommended SSHing into the NAS and deleting the newer Intel Drivers as another solution, is that recommended over this preferences change?
I ask because, based on version , the location has changed. It’s recently been made accessible in FileStation for backups and emergency purposes.
Before that. Deleting drivers is A) radical B) unwarranted without knowing the real problem and C) most likely will not be beneficial if the subtitles are being burned into the video because almost all Synology NAS systems are incapable of burning subtitles due to their weaker processors.
I was just coming back here to say that I realized I was running 1.24.1.xxxxxx and just updated to 1.24.3.xxx and now I see the folder in File Station. I really thought I was going crazy.
I did run into a minor snag with the Syno Text Editor, for whatever reason it wasn’t allowing me to edit the preferences.xml file, saying I didn’t have permissions, even though I set my user to have permissions over the entire Plex share and then specifically did a permission check on the file itself. I ended up just downloading to desktop, editing in notepad and reuploading to get around.
I can now confirm with the VaapiDriver=“i965” fix that in immediate testing my problematic file does appear to transcode well now (Playing on Roku Ultra the stream “health” is listed as a 1.2-1.3 now).
Questions: what are users who apply this hot-fix giving up by setting this VaapiDriver=“i965” preference (is it worth it if you only have a handful of issue files)? Is this THE recommended fix for this issue? Will there ever be a time in the future when we can remove this and play image based subs properly on clients that must have them transcoded by the server? Will this preference stick through updates or does it need to be reapplied every so often?
The PlexMediaServer shared folder is owned by user PlexMediaServer.
You must be VERY careful if you modify anything because there is no way to correct the ownership via the GUI.
I made the share accessible to allow backups (primarily)
Please review the Release Notes posted here in the forum.
The limitations are because of DSM 7. DSM 7 has removed ALL administrator capabilities for applications. I , as package author, don’t even do the actual install & setup anymore – DSM does. it also allocates and grants access to requested resources if they are available. It’s very ugly.
So, I think I may have fudged something potentially. Everything appeared to be working okay, and just on a whim I stopped Plex from the Package Center and restarted it. After the restart I am getting no connection to the server/content. When I open the Plex app from the Syno desktop it just spins on the server endlessly. Maybe this has something to do with the Permissioning?
Additional Info EDIT:
So I read where you state in the package release notes:
“If file permissions or ownership are altered then a User-Script scheduled task or manual intervention on the command line will correct the problem.”
I’m pretty sure this is what my problem is, because I know I monkeyed around with the permissions trying to edit the dang preferences.xml file. Would I be best to just manually reupload the package, will that give me a fresh install and permissioning of 1.24.3.xxxxxx?
Sorry, I guess I assumed you remembered the 50+ back and forth replies in this thread from half a year ago. In it, we’d discussed this particular issue before (and others, like color streaking for lower quality transcodes) and settled on what I thought at the time was a temporary solution of using this VAAPI 965 driver while it sounded like you said a fix was incoming. None of the updates since mentioned a fix like this, and no further reply came to this thread. So I just got frustrated.
As for this particular issue, I know for a fact that SRT subs run fine under the default driver. Most likely because it does not need to burn those in. If I forced subs, I ASSUME it would also perform badly. Alas, I am no longer able to perform tests for you, as I have since upgraded my server to a docker-based server on a nice hand-built system.
…
Actually, since I am no longer using the old server, I suppose that means I can do whatever tests I want to it. Give me some time (hour or 3) to find a moment when the new server is not doing anything important so I can shut it down. Since I re-used the old preferences.xml, it appears to have taken over the old server’s ID, and I am afraid of running both at once for fear of a conflict.
All of a sudden I woke up this morning and things are back to working again… I have no idea why the server went non-responsive last night… It worries me though because now I don’t know if and when it will randomly do that again. Wondering if I should do a clean install of the 1.24.3.xxxx update. Suggestions?
Just chiming to say that I appreciate the detailed discussion on how subtitles actually work here, ChuckPa’s diagram on the actual process especially. I’ve had similar problems with PGS subtitles on a Synology 920+ playing on a Chromecast Ultra and while changing the driver in preferences.xml has addressed the stuttering in the short term, I think I understand the underlying issues much better now than when I had first applied the fix. Suggests to me that I need to put in the legwork to convert my PGS subs to SRT or set something up with more power. Thank you!
I just wanted to chime in to say that I encountered this issue on my DS920+ with the current PMS version as of December 2021, and the fix mentioned above (adding VaapiDriver=“i965” to the the preferences file) resolved my issue.
Previously I was not able to play even a single stream with ASS subtitles without constant buffering, but changing the driver allowed me to simultaneously transcode two ASS subtitle streams (hw transcoding enabled) with some CPU to spare. My client, an Nvidia Shield Pro, does not support direct play with ASS subtitles, so it was transcoding every time.
It’s a bummer to see that this is such a long running issue but I appreciate the in depth discussion above and am happy to have a work around.
Same problem on the same device - the mitigation described in the previous post worked for me also with hardware transcoding enabled. Before i was suffering from the constant buffering issue every 2 seconds when subtitles were enabled.
I am going to add a caveat to my VaapiDriver="i965" setting.
If you have HEVC HDR (HDR+, HDR DV) content , above 40 Mbps (video rate),
Don’t use the i965 driver.
I ran into this with re-ripping my discs. The problem stems from the UPPER limit of the i965 ASIC in the CPU. It can’t handle the higher bit rates. Its design maxes out bandwith as you get to 50. Documentation says 90Mbps but practical experience shows video tearing / failure above about 50 Mbps.
Ouch. Well, all my content is well below 5, so not an issue. Plus, I moved on to a beefy self-built server in a docker config.
Any progress on why this issue happened at all? Seems to me a HW transcode that has to retranscode a sub shouldn’t perform horrendously worse than a SW transcode.
The issue about how hold the i965 circuits are and their designed bandwidth limits ?
-or-
The issue about not doing subtitles in hardware ( VAAPI never could do that )
IF this is about ASS subtitles – specifically – please help me put some examples together and I’ll start
The one way back in June 5th here, you appeared to have found a solution.
The issue being that these Synology NAS devcies can do subtitle burn-in using software perfectly fine (using up most of the CPU) and still come out ahead of real-time play. But once you turn on hardware transcoding, suddenly the same video (with subs being burned-in) buffers 15-20 seconds to play 2 seconds of video. Both situations are doing burn-in subs, but HW our devices fall flat on their face, not performing fast enough at all.
The use of the alternate VAAPI driver was supposed to be a bandaid fix. And you point out it doesn’t work at all if the bitrate of the video is high (but I doubt anyone using a Synology NAS server will be using 50+ Mbps videos transcoding anyway).
We still get posts here every few weeks of people having this issue, and having the alternate driver fix it.
