Hello guys. I got no success (not even replies) on the Plex official forum, so hopefully someone here could help me.
Getting to the business. Recently setted up plexinc/pms-docker container, everything works fine, except subtitles in android app. Nevermind them, selected integrated player, which can not decode mkv files, so it needs transcoding, and after that subtitles show up (burned in). But transcoding is awfully slow, to the point it’s pretty much useless. I actually need it, because most of my media is fairly high quality for home watching, and I don’t need (neither can due to mobile bandwidth) watch this heavy videos directly on my phone.
Server has 2x Xeons e5 2620, 16gb of ram, running debian 9.5 with latest official docker image, transcoding folder is on ssd, media itself on a 7,2k rpm drive.
Tried allocating second cpu (6 cores and 12 threads) completely to container through docker, no changes. Tested running PMS natively on debian, it was butter smooth for half an hour, after that same thing.
What can be the source of an issue(s)?
My first guess was hardware transcoding wasn’t working inside the container, but the 2620 doesn’t support quicksync anyway. Also you’d need plex pass.
Xeon 2620 should be fast enough to transcode 1080p h.264 in software. Maybe not h.265/HEVC, but h.264 should be possible.
Since it slowed down after half an hour, it probably isn’t a docker thing. My guess is something else is using resources on your server or (if you’re streaming outside the home) using up your bandwidth. Check with htop, iotop, and nethogs.
I don’t have any gpus (except asmedia, lol) in my server, so hw was out of question.
Here are examples of htop report during idle
You don’t need a separate GPU, quicksync is the built-in hardware encode block in relatively modern Intel CPUs. I think it started with Sandy Bridge, but your Xeon doesn’t have it.
From htop it is clearly pegging your CPU, so I guess the 2620’s single-threaded performance isn’t fast enough to encode h.264 in software. You can go into the plex media server transcoder settings and switch it to “prefer higher speed”. That should sacrifice a bit of quality for performance.
Yeah, from a bit of research, transcoding a single 1080p h.264 stream in software requires roughly a 2000 score in passmark, and your e5-2620 only gets 1225. A contemporary i7-2700k with much higher clockspeed has a single-threaded passmark of 2008.
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Xeon+E5-2620+@+2.00GHz
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i7-2700K+%40+3.50GHz&id=881
I tried changing transcoder settings, no difference even with lowest quality presents. However when it worked, it worked with “medium” speed and “prefer quality” setting good enough to even increase transcoding quality. Nothing was manually changed since then.
iotop btw just for the sake of it:
Well, you should try turning everything else off including bittorrent, but I doubt that will help as it appears to be single-core CPU bound. You’ve got a crapton of cores, but they’re all pretty slow.
In this case I wonder why is transcoding so good just after Plex installation? And slows dramatically during some little amount of time.
Would completely recreate docker container tomorrow and try to recreate this.
Also to watch out for - Some codecs don’t support multithreaded transcoding so these codecs will be limited to a single core.
#Edit - Users have reported that disabling hypertheading can increase transcoding speed.
All testing was done on a single file in MKV container, outputting h264 video with burning in ASS subtitles.
Thanks for HT advice, would try this when I get desperate.
https://support.plex.tv/articles/201774043-what-kind-of-cpu-do-i-need-for-my-server/
According to the above article and this score for your processor:
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Xeon+E5-2620+@+2.00GHz
The single threaded score for your CPU is at the limit to a bit low for that bitrate in situations where the transcoder can’t use multiple threads. I would say disable HT to ensure maximum single core performance and if all else fails try reincoding the media to a different codec with the sub’s burned in to see if that helps.
From what I read VC1 codec doesn’t support multithreaded transcoding. As a second thing that can impact the speed sometimes subtitles can cause significantly more load on a single core as well when transcoding.
htop screenshots above shows that multiple cores are being used, and again, this concrete file plays ideally just after PMS installation, first ever usage was through mobile network and VPN with burning in subs, worked great. Not the case after some additional time. So for some reason my cpu is powerful enough from the beginning, but perfomance drastically degrades after some mystic event, it does not depend on containerising, receiving device or network, drives are not an issue either.
You could always try using a utility like ffmpeg to transcode and see how much of a difference it makes compared to Plex. Maybe it will have less overhead? But then, is that worth the cost of manually (or scripted) transcoding vs allowing Plex to handle it internally?
I use ffmpeg, but I like getting my hands dirty.
I’ve used Emby to stream Blu-ray mkvs from a VM on an E5520 without issue. It uses ffmpeg.
It’s possible your drive is the bottleneck. How full is it?
There is an iotop screenshot above, about 30gigs free on ssd (transcoding temp directory) and 3tb (media directory). Transcoding files never used all 30g available.
Worring about drive bottlenecking was actually the reason I use ssd for transcoding dir now, but this did not seem to help.
So I’ve got some interesting results in ffmpeg. All tests were done with containers and PMS stopped, output folder was on ssd, original file on 7.2k rpm drive.
Tried ultrafast preset, got single digit fps.
But then I tried Slow preset in the absolute same conditions and got up to 55 fps (for a second though, fell down to around 30 quickly and stayed there after):
However, my second try with slow preset gave me less then 10 fps again, and it stays consistent now:
So same odd behavior as Plex. Strange reaction to presets, works ok first and slows down after SOMETHING.
What can be causing this crap?
At work, so I won’t be able to help troubleshoot much until later, but try using “-vsync 2” as an argument for ffmpeg. It typically defaults to 1, for whatever nonsensical reason.
Well, it gave me 2 fps. -vsync 0 resulted in 10-12.
This fixed the issue completely, I disabled HT and now I get consistent 80+ fps in ffmpeg with slow preset:
and completely smooth transcoding in Plex.
And it just horrifies me. HT has been around since Pentium 4, if my memory serves me well, and ffmpeg and whatever-transcoder-plex-uses developers didn’t ensure using real threads instead of supporting ones? Game devs figured it out ages ago.
Anyway, thanks for your reply, you saved me here.
That is really interesting! Must be a weird HT implementation on your old Xeon. My next guess was going to be NUMA.
My desktop has 3770k, and it’s basically a Sandy Bridge on 22nm. HT on it is completely fine. Ryzen had similar issues in games on launch, apps couldn’t distinguish threads with it’s new SMT technology, but it was fixed relatively quickly.