Server Version#: 1.18.9.2571
Player Version#: n/a (Chromecast Ultra)
Hey guys,
Just wanted to play a video with ASS subs (i.e. needs a transcode). I’m barely getting 0.6x - 0.7x transcode speeds, with constant sound stuttering and video pausing briefly over and over again, unless I stop playback for 5 minutes and resume. Trancoder CPU usage is barely 20%. Material is 1080p. TL;DR: unplayable (I’m casting to a Chromecast Ultra)
I’ve disabled hardware encoding to check and transcode speed immediately jumped to 3x, playback is perfect
How is this possible? I remember hardware encoding being fine a few Plex versions ago, did something break again? Source isn’t 10bit, it’s not even high bitrate or some 5.x profile. Just an average H264@L4 High. I’m confused
Mediainfo:
General
Format : Matroska
Format version : Version 4
File size : 5.10 GiB
Overall bit rate : 8 119 kb/s
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 h 29 min
Nominal bit rate : 8 000 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.161
Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : A_AAC-2
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 44.1 kHz
Frame rate : 43.066 FPS (1024 SPF)
Compression mode : Lossy
Text
ID : 3
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Compression mode : Lossless
I have no idea where you got that theory from, it’s just wrong and makes no sense even based on what I already wrote above, sorry.
To add to the conversation I have some more data:
Software encoding speed varies from 1.6x to 3.0x, mostly around 2.0 range. CPU usage is between 70% and 90% for the Transcoder. until it throttles itself later on. Player bitrate is 12.1Mbps (“Original”). Playback is completely fine and smooth.
Hardware transcoding ends up buffering and choppy with the same quality - 12.1Mbps selected.. Reported transcoding speed is anywhere between 0.5 and 1.1x at best. Mostly 0.7x. Transcoder CPU usage never exceeds 20%. Playback gets choppy after a minute, with sound glitching out first and then video repeatedly pausing to buffer up
So no, hardware encoding isn’t doubling the workload on the CPU which is quite clear when you look at CPU usage, and software transcoding definitely isn’t reducing the workload on the CPU by a small margin.
Even if burning subtitles causes the transcoder to fall back to software, it just makes no sense to throttle itself below playable threshold and keep chugging (also imo it should be clearly noted that it’s falling back to software, but it’s still listing that the HW encoder is being used
I’m afraid I’m not overlooking anything. I wonder what you’re basing your theories on
You’re missing the point. The CPU has more than enough power to process subtitles and the video as proven by the 2.x transcode speed on SW. There is no CPU bottleneck. The bottleneck is transcoding logic which my thread is about. If what you’re saying was true than I’d be seeing 100% CPU utilization while the system struggles to software-encode subtitles on top of the video. I’ve provided proof that this isn’t the case. CPU usage is 20% when HW is on.
You’re right that those two don’t run at the same rate, they can’t because they depend on each other. They’re definitely not simultaneous though.
It’s not about about being CPU-bound. If anything I’d assume that HW encoder only uses a single thread for some reason
EDIT: after searching for new keywords, I conclude that we were both partially right, HW encoder seems to lock transcoding to a single core, but your arguments lost a lot of background and were incomplete - that’s why I was arguing. The root cause is not because CPU doesn’t have enough power or that it needs to stay in sync, it’s that because HW acceleration in Plex locks itself to a single CPU core it’s not able to process burning subs fast enough and that apparently A/V sync has to be done on the same core. With multiple threads running at the same time this limit is no longer relevant and having multiple threads outweights the gains from hardware acceleration
So I guess the best solution was if Plex would allow to disable hardware acceleration when subtitles are being burned, but keep it on otherwise
Thanks for guiding me in the right direction
May I ask which DiskStation model is in use here?
Hey @ChuckPa, Sorry I can’t believe I totally forgot to add it lol. Synology DS918+, running natively off the package (not docker)
I think I was able to answer my own “why” question thanks to @trumpy81’s comments guiding me in the right direction. Looks to be the single-core limit of HW acceleration as discussed in another thread where burning subs is just too much for a single CPU core to handle and it kills performance.
I’d appreciate any further insight / confirmation though 
If I may shine some history?
-
Trumpy was previously the primary support Ninja for the Synology forum but stepped back for personal reasons. I’m the engineer who’s stepped up to fill his shoes in addition to my normal activities.
-
All subtitle processing is single-threaded. This is a limitation of the FFMPEG base which Plex uses. On the DS-918+'s quad core J3455 CPU, burning of subtitles will show as 25%
-
The transcoder itself is multi-thread for video. Audio transcoding is single threaded software only conversion. Subtitle burning is software only image generation and merging into video frame outputted by the Intel QSV ASIC which does the actual transcoding.
H.264 -> H.264 conversion with subtitle burning should require:
- 1 core to perform I/O - partial duty
- 1 core to perform the actual ASIC communication (partial based on buffer status)
- 1 core to burn the subtitles into the output buffer which came from the ASIC. - Dedicated = 25% CPU load in all cases.
The output multiplexing stage of FFMPEG (transcoder) has to wait for all the pieces to done otherwise the resultant output stream is garbage. agreed?
It’s not uncommon on the J3455 to see a load of 25% when transcoding without subtitles: Input, qsv handler, output multiplexer.
Now add subtitles. there’s another core. That’s the best it can do in optimum circumstances. the limitation here is ‘single-thread speed’.
Does this help ?
- I stand corrected and sent back to my seat, I didn’t want to come out as an arguing ■■■■■ (oh wow it censors it, but you know what I mean). However just to explain the reason I kept arguing: reasoning he presented made no sense to me. He didn’t use “thread” or “core” anywhere and was only referring to “CPU” as a package, while I already presented data that CPU (as a “package”) was being bored during HW accel’d transcoding
- Got it, that confirms it yes
- Right
The output multiplexing stage of FFMPEG (transcoder) has to wait for all the pieces to done otherwise the resultant output stream is garbage. agreed?
Agreed, all pieces need to be muxed back together for a usable stream to be presented to the receiver
Thanks, it definitely helps, but while it makes sense it still kinda sorta doesn’t really explain why if just one thread is responsible for burning subtitles onto the video regardless of HW/SW encoding, having HW encoder cripples the process so hard - I guess I’m trying to understand the underlying cause for the bottleneck i.e. what element of the process puzzle is causing this. Either that or I’m now getting confused myself 
@trumpy81 sorry man, yeah the way you worded it really made me think I’m talking to someone who just heard it somewhere lol. Props for using language easy for others to understand though
And thanks for technical details!
Now that we’re in sync, this is likely to be the missing piece of the puzzle.
When PMS updated the transcoder in 1.17.0, there was a regression in how ASS subtitles were communicated between PMS and the transcoder itself. It only impacted ASS. It was not uncommon to see a fully spinning CPU (90+%) when ASS was involved.
Do you have SRT subtitles which you can use now to compare your version of PMS for comparison to see if ASS had regressed again?
Regarding that “single threaded subtitle burning” – that’s how FFMPEG is written. It’s a string of characters which are converted to bitmap images which are then dropped into the video frames. It really is a single-threaded operation because of how the FFMPEG pipeline works.
Unfortunately this seems to not be limited to ASS. (File is using ASS since it’s a fansub)
I converted to SRT using some random online converter and it’s still very much struggling to smoothly convert the video with constant pausing and audio hiccups and CPU barely reaching 25% usage. Interestingly with the SRT transcode speed is reported as 0.0x
If I disable hardware acceleration, just like before, I get 90-100% CPU usage and smooth playback and good transcoding speed (up to 3x)
I guess I could try downgrading Plex to check? Would you be able to suggest any specific version?
Is the sub internal or external? It sounds like this is an external sub.
That might be the regression which had previously occurred having recurred again.
If it’s external, do you have mkvtoolnix / mkvtoolnix GUI to merge it as internal?
Strangly, that made a difference.
forgot to add. (hour is late here). the “speed” indicator isn’t reliable since hardware transcoding came into the picture. CPU load (or directly with top) is how to see what’s happening.
SSA is internal (as per MediaInfo in the 1st post), SRT was external (I just put it there after conversion as a file next to the video with the same name)
I can totally remux (part of) the video with SRT to check, but that’s gotta wait about 14 hours 
14 hours?
I can split out subs or remux them back in in a few minutes for even 30GB files.
What are you using? shoe-string ethernet ?
Hahahah nope, just leaving for work in 10 minutes and have to get ready 
I’ll report back as soon as I can
Sucks to be you! 
I’m about to sleep (03.25a here).
Have a great day. we’ll pick this up when you return.
Hey!
Sorry, bit late with the reply - was tricky because Chromecast just direct plays any h264 with internal SRT and I was unable to force a transcode regardless of the quality setting selected
After fiddling with the browser player and changing some subtitle burning settings I was able to force it to transcode to a similar bitrate (11.4Mbps) as previously
With hardware acceleration enabled, the playback was still pausing to buffer up. Wasn’t as bad as ASS on Chromecast but definitely not a usable experience. Server CPU usage around 20%
Screenshot from paused playback, while transcoding it was showing 0.7-1.1 speed
P.S. To clarify the remuxed file has ASS subtitles removed and only SRT ones inside
Given what you show:
- Container change MKV -> MP4 (CPU tasking)
- Video bitrate change -> Video ASIC
- Audio conversion (CPU tasking)
- SRT burning (CPU tasking).
Don’t trust the speeds anymore with hardware involved.
The audio and subtitles are going to follow what’s needed for keeping the buffer filled.
Is the real concern here why the CPU load is so low and why the logged rate isn’t a high number?
Gotcha. I kept adding them because whenever they were below 1 I actually could notice interruptions in playback. When they were above 1 playback was fine. Might not be precise but seems to match what I’m seeing
The real concern for this thread is that, with hardware acceleration enabled, videos that need subtitles burned (of any type, it seems, and regardless of container) are stuttering due to not being transcoded fast enough, with relatively low CPU usage, which makes them unwatchable. And whether or not there are plans to check and possibly fix this
There’s no easily accessible switch to turn acceleration on or off per video. It’s either on for all or off for all, with an option hidden in settings
This kinda kills the purpose of hardware acceleration since it’s a big selling point for Plex Pass
I’ll try downgrading to a version that I think worked better and compare next
This point, is a limitation of Synology hardware and always has been.
The single-thread speed of all the Synolog NAS boxes, with exception of the Xeon boxes, is pathetic.
The only viable solution has been to avoid burn-in by:
- Using Text-based on players which accept text-based
- Burn-in the subtitles permanently before giving the file to Plex.
It’s been this way for many years now. It’s also why I went to QNAP for my next NAS.
1 Like
