Plex Server cannot handle transcoding with subtitles

[MagaZine]

Server Version#: 1.22.3
Player Version#: 8.16.2 (Android TV)

So, I have a Synology NAS (DS920+) and for some reason, it just can’t handle transcoding if it involves subtitles not supported on the client device (even with hw decode/encode turned on & working).

Specifically, I’m trying to play a 1080p h265 video that has vobsub external subtitles on an Android TV device.

Now with subtitles off, the video direct streams and the audio gets transcoded (since my soundbar doesn’t support multi-channel aac). This works great with zero issues. However, if the vobsub subtitles are enabled, then the transcoding lags heavily. It takes up to a minute just to play the file and then after that, I only get a few seconds of playback before buffering up to 30 secs a time, rinse & repeat until I quit playback.

Why is this happening?

When not burning subs into the video, my PMS can handle a couple 4K streams transcoded down to 1080p w/ audio just fine. But, add subtitles and suddenly playback is like if I’ve turned on HDR tone mapping or something. It’s so excruciating slow. I’ve tried the old ‘pause the video and wait couple minuets to add some breathing space’ but this only works… for a couple of minutes before I’m back in buffering hell.

I’ve checked CPU usage during this time and my NAS hovers anywhere between 25-50% whilst RAM usage (8gb, dual channel) is at around 22%. This whole thing is just very confusing and so I’d appreciate if anyone can help me out.

–

Also, sidenote, why doesn’t exoplayer support vobsub subtitles? I’ve tested both my Android TV & Android phone (with VLC player) and they playback the above-mentioned video & subtitles just fine. So, I know this is a software issue with Plex’s player rather than a hardware limitation. Is there any chance this support would be added sometime in the future?

[MagaZine]

Would you mind explaining to me what PMS does exactly when burning graphic based subtitles that causes the low performance? I looked at the PMS console and thought I got a vague idea but still not sure what exactly happens. And is there a reason why subtitles can’t be handled using a multi-threaded process?

I know at the end of the day the NAS just has a lowly Celeron but you know it’s powerful enough to smoothly transcode 4K h265 SDR in software-only mode, so I was surprised to see that those specific type of subtitles would bring it to its knees.

And lastly, what are the differences between ‘Automatic’ & ‘Only Image Formats’ options? .srt subtitles play fine without transcoding when on automatic so just curious. Thanks.

[RockStar]

I really dont think your celeron can sw transcode 4K. Its far from powerful enough.

[skwor01]

You have plex pass, pretty sure your DS 920 is using hardware transcoding.

Your device is not rated to software transcode 4k
see compatibility chart:

Plex NAS Compatibility

[MagaZine]

To be fair, it’s not high bit rate 4K but I mean, I did just test it to make sure I wasn’t just making up things.

You can see for yourself can see here (15mbps 4k sdr h265):

[MagaZine]

Yeah, no I got hw acceleration fully turned on for my regular usage.

I just mentioned software transcoded 4K to show some disparity (my NAS can’t burn subs apparently but can sw transcode lower bit rate 4k files).

Also, that spreadsheet uses a 60Mbps 4K file to test, which is fair, but I do not have any high bitrate 4K videos in my library (if I want that, then I just pop in a 4K Blu-ray to my player for maximum quality). Most average around 15-30Mbps. With Web only releases in that lower bound I just mentioned and those are the ones that I can confidently transcode in software when testing.

[MagaZine]

Excuse my long reply, but this issue just got much weirder for me and I think a deeper inspection is required via Plex.

So, I just installed emby media server on my diskstation to test out whether or not I have the same crappy playback as I did with Plex. Since emby on Android uses exoplayer too (which as you know has no support for VOBSUBs), the expected behaviour is that yes, it should perform just as badly if not more so since I won’t have access to h/w encoding.

Well, surprisingly, the absolute opposite occurred. My video started playback fast and then played smoothly without hiccups or buffering. Suffice to say, I was shocked. I verified it was transcoding the video and it was in software mode with the reasoning being that the subtitles weren’t supported. And not only did it play smoothly, but it transcoded fast too (at around 50fps with 1:30s worth of buffer after 60 secs of playback).

Now wasn’t I told a few hours ago right here that apparently my CPU is way too weak to handle burning subtitles and transcoding video at the same time?? How is this working then? I was honestly baffled but I thought I could replicate the same behaviour in Plex. So, I went in and disable both hardware encode & decode and started playback on my device and wow, smooth playback performance with a decent buffer (with the speed fluctuating between 1.2 - 1.8x according to Tautulli).

Ok, so it seems there’s an issue here with hardware acceleration and the burning of image format subtitles that causes transcoding performance to tank. This obviously shouldn’t be the expected behaviour and I think requires further investigation.

But wait, there’s more. I did some further digging in my library and found many files that had VOBSUBs muxed in and are therefore embedded within the file. So, I tried playing one of them and what do you know: it direct played the entire file!
With this finding, I went back to the original file I made this post about, took the external VOBSUBs and muxed them into the file. Put this new file in my library and just as expected, the file now direct played with no transcoding needed.

Therefore, it turns out I lied in my second paragraph. Exoplayer does support VOBSUBs as long as they are not external and are instead embedded in the file. Again, I don’t think this should be the expected behaviour and this too needs to be investigated.

TL;DR

1. The Synology DS920+ with the Celeron J4125 absolutely can transcode video & burn graphics-based subtitles at the same time contrary to what @trumpy81 said IF hardware transcoding is turned off. This doesn’t sound right and needs to be investigated.
2. Exoplayer v2 (and therefore Android mobile/Android TV) does support embedded VOBSUBs meaning transcoding can be entirely avoided and hardware acceleration left on as long as any external VOBSUBs are muxed into the original video.
3. If you do have any embedded PGS/VOBSUB subtitles in your videos, do NOT change the burn subtitles option in your client app (in my specific scenario: Android) to ‘only image formats’ because then, those once direct-playable subs will go the dreaded way of the transcoder

[ChuckPa]

Please be careful with the separation of Server issue versus Player issues here ?

Speaking to the transcoding capabilities of PMS on a DS920+ NAS:

1. HW decode of HEVC HDR 2160p
2. HW encode of H.264 1080p
3. No HW tone mapping of HDR content at this time. Engineering is working on it.

CPU utilization-

1. Quad core processor
2. Full monopolization of a single core (single thread) == 25%
3. Video Decode is multi-threaded - depends on codec but typically 3-4% with HW
4. Video Encode is multi-threaded - depends on codec but typically 3-4% with HW
5. Audio transcoding is multi-threaded - typically 10-15% but up to 25% per stream
6. Subtitle burning (Image based)
   a. When the player is not capable or option is set to force burning
   b. Can consume an entire CPU core (additional “25%” usage)

WARNINGS

1. On Synology NAS systems, Until Engineering provides us with HW HDR tone mapping —
2. Software Tone Mapping – will kill the CPU – Be careful with HDR content

[MagaZine]

Yeah, my bad. Did get a little mixed up there with the messaging.

So let me be clearer with my problem.
My principal issue here is with the burning of image-based subtitles as it relates to hardware accelerated transcoding on PMS.

Specifically, with HW encode/decode turned on, playback performance is rubbish and unwatchable due to constant buffering when transcoding a video due to image-based subtitles.

With HW encode/decode turned off, playback performance is all around satisfactory with smooth playback when transcoding a video due to image-based subtitles.

Why is this and is this the expected behaviour with a NAS?

Whilst the HW encode/decode off method does work for image-based subtitles it’s definitely not preferred since its pegs the CPU at 90% usage and prevents any other user from transcoding.

–

With regards to HW HDR tone mapping:
Good to hear it’s still being worked on (it is a feature I’m looking forward too) but I’m not too fussed with its current non-inclusion since all my devices bar my PC support HDR (and last I checked, Plex for Windows can do client-side tone mapping when direct-playing so not a problem).

[ChuckPa]

@MagaZine

I need the logs please.

This is not making ANY sense now.

May I please see separate DEBUG logging ZIP sets for each of the conditions using the same input file and same player ? ( keep player settings the same during both tests )

1. HW enabled
2. HW disabled

To generate:

1. Start Playback
2. Let play 20 seconds
3. Stop Playback
4. Wait 20 seconds to flush to disk
5. Download Logs ZIP file

[MagaZine]

As requested,

HW enabled logs:
HW Enabled PMS Logs.zip (4.1 MB)

HW disabled logs:
HW Disabled PMS Logs.zip (4.1 MB)

[ChuckPa]

I’ve asked the Android team to look here.

I see things I do not understand about how the Android app makes requests.

I use Apple devices and an Nvidia Shield. Those don’t look at all like Android mobile devices.

[Divideby0]

I’d be interested in this as well. I also have a DS 920+ model, and my plex server faceplanted when it came to certain files. After exploring a bit, it seemed to do with the image subtitles (PGS, Vobsub, etc). Interestingly, when I turned off HW transcoding of video, it was able to run those just fine. Since I like HW transcode (uses far less cpu time for a stream), I just vowed to try to avoid PGS subs in my shows.

I seem to recall the explanation for this at the time is that plex cannot hardware transcode the video AND THEN burn in the subtitle. So it seems to fall back to software transcode, and then does it AGAIN to add in the subtitle. This strange combo of transcoding twice I think causes the DS to just fall so far behind. Like, 15 seconds of buffer to play 2 seconds of video kind of fall-behind.

I don’t recall at this moment whether I noticed the slow playback on any device other than my Nvidia Shield. Most of my views nowadays are using the app.plex site in my chrome browser.

[ChuckPa]

Burning subtitles is the bane of every Synology server due to the limited CPU power available. Synology did not deem it appropriate to offer models with more CPU horsespower.

First, the normal process (assuming HEVC HDR content)

1. HW decode
2. Subtitle-burning
3. HW encode
4. HW tone mapping.

The player has a great deal of control here.

If the player is set to “Always Burn” subtitles then Subtitle burning will be performed regardless of what the player can do. In this case, an otherwise DirectPlay scenario (The Nvidia Shield app can handle its own) has turned into a full transcode.

The Shield Pro can

1. Decode locally
2. Burn any subtitles locally
3. Encode locally
4. Use the Nvidia Experience tone mapping engine

My first suggestion is to go into the Nvidia player settings and make certain everything is set to automatic and then retest.

[FordGuy61]

@Divideby0

Most of my views nowadays are using the app.plex site in my chrome browser.

If watching on a PC or Mac, try Plex for Window/Mac instead of Chrome.

Plex for Win/Mac direct plays most media. It also scales/tonemaps 4K HDR when watching on a SDR display.

Plex for Windows on 1080p SDR display:

[Divideby0]

I wanted to clarify that the issue appears to come when you have to transcode audio. This somehow forces the subtitles to be burned in, even if they are SRT or SSA. This second transcode when the video itself is already software seems to cause the NAS to fall flat on its face and transcode much much slower than normal. If you disable HW transcoding on the server, then it apparently can burn in the subtitle if it needs to on the first pass, which will be fast enough for playback without any trouble (but uses a lot of CPU power, and now all streams need to be SW encoded and use up more CPU too).

@FordGuy61

If watching on a PC or Mac, try Plex for Window/Mac instead of Chrome.

Plex for Win/Mac direct plays most media. It also scales/tonemaps 4K HDR when watching on a SDR display.

Yeah, maybe I ought to do that I suppose. I’ve got no problems, and I like the ability to treat it like a netflix or youtube tab, but if it visually is the same then there’s not much problem. I got my friend to do that to view the subs on an anime, when I found out for some reason his copy of firefox was forcing the server to transcode the audio from AAC (stereo) to AAC. The same video on my own computer, on an older firefox and my newer chrome window, do not need to transcode the audio track and thus don’t trigger the dreaded “burn-in subtitles and HW transcode video” double-punch.

[ChuckPa]

I’m sorry if I’ve not understood.

Here’s what I’m trying to show about the Nvidia Shield app

No transcoding is required for anything including subtitles.

If this is what you’re trying to achieve, please let me know and I’ll be happy to help in any way I can.

[Divideby0]

I may be dragging this subject off-topic, but the issue with Synology and HW transcoding and subtitles is oddly particular, and it has nothing to do with the player it is watched on. Basically, IF the server is set to HW transcode, a file will run just fine. But as soon as you have to burn-in a subtitle (whether you force it for all sub types, forced for image subs, or incompatible player that needs burned text), the HW transcode falls flat on its face and the server is unable to keep up. In fact, it seems to play about 1 or 2 seconds of video for every 15 seconds of buffering.

If you disable HW transcoding on Plex side ahead of time, and do the exact same video (and burn in the sub), it plays fine. The CPU is used a lot more than if you hadn’t, but the same video on the same player with the same subs runs at full speed.

The issue here is why does this happen? If it eventually has to fall back on software encoding the file (because the CPU can’t burn-in the sub using hardware), then why does it perform much worse than when software transcoding in the first place? If it’s due to it double-dipping (HW transcode video then SW transcode again for the subs) why not have Plex fall back and do software from the beginning? This would avoid the really strange case where HW transcoding with a burn-in sub just crashing and burning.

[ChuckPa]

@Divideby0

But as soon as you have to burn-in a subtitle (whether you force it for all sub types, forced for image subs, or incompatible player that needs burned text), the HW transcode falls flat on its face and the server is unable to keep up. In fact, it seems to play about 1 or 2 seconds of video for every 15 seconds of buffering.

On Nvidia Shield, Leave it on AUTOMATIC. The Shield app will let the Syno send it the subtitles and it will do the rendering internally itself.

When you FORCE “Burn In” you’re going to make the Synology do it – which it is just NOT up to the task for.

The goal , whenever using Nvidia Shield is “DirectPlay”.

[Divideby0]

Even with image subs? Back when I first setup my Plex server, it was fantastic and I loved it. But the first PGS/VOB file I played with it and it played horribly slow. I don’t think I messed with forcing burn-in on the server, but maybe I did. If so, it’d explain why it didn’t work well, but you claim the Shield is capable of doing it on its own end.

Regardless, there is still an issue server-wise when it comes to burning in subs and HW transcoding on Synology. Could you explain why:
HW transcode + subtitle burn-in (for whatever reason you are doing it) + Synology NAS server = crash and burn?

edit: looks like the subtitle burn-in option I’ve been referring to is for the Web player only. I am only now noticing that settings under “Plex Web” are for anyone else who watches plex videos using the Plex Web player, and do not apply to any other player.