I’m trying to understand why some 4k files are playing fine and others are not. my server is definitely powerful enough. it seems that some files when played back are not using my server to it’s full potential.
Server:
windows 10 pro
E5-2680v2 - 2.8GHz 10-core CPU (boost up to 3.1GHz)
32GB DDR3-1333 ram
intel SSD for OS
data stored on a Synology DS416 NAS
for example,
I have 4k “title A”:
52Mbps bitrate
HEVC (Main10@L5.1@High)
playback is smooth, and CPU usage is about 75-80%
i have 4k “title B”:
65Mbps bitrate
HEVC (Main10@L5.1@High)
playbak is not smooth, constantly buffers, CPU usage only about 25-30%
both files playing back on my 1080p TV via Amazon Fire TV gen3, but i get identical behavior if i playback at 720p on my iphone or any other device.
so why is plex not utilizing all available resources to have smooth playback on some files, but not others? they appear to be more or less encoded identically. I cant seem to identify the issue here.
The server log files will show the rate of transcoding - if it’s less than 1 that means it can’t keep up realtime, if it’s greater than 1 then it is having no problems keeping up. If you close your Plex Server, wait one minute, start it, wait two minutes, use a client and play back the “4k title B” that doesn’t play smoothly, wait until it buffers, then grab the log files (server settings -> help) and upload them here, I’ll take a look for you.
Chuck. I’m aware of the CPU specs. But as I’ve already noted, the CPU has no problem with other 4K 10-bit context. Yes it’s stressung the CPU a good amount using 75-80% of the CPU, but it handles it.
When I play the problem file, it’s only using 25-30% CPU, not stressing it at all. So I don’t teallu buy the argument that the CPU can’t handle it if it’s not even maxed out. I’m trying to figure out what it is that’s causing Plex to not be able to use more cpu power on this file.
Is the Problem Child a VC-1 encoded video? A lot are. VC-1 is a largely single-threaded decode whereas H.264 is much more multi-threaded and can utilize the CPU
It is my understanding that HEVC (h.265) will multi-thread.
Check it this way>
ps huH p <PID_OF_U_PROCESS> | wc -l
or use top and hit H to see thread listing
or look in /proc/<pid>/task and count them.
In the interim, I will check with the transcoder team but if some of your videos play ok while others don’t, it will be difficult to find a transcoder/codec fault.
@j.koopmann said:
I was just about to order a new X5-2680 v2 based NAS for the purpose of transcoding h.265 where necessary. I am very interested in the outcome…
what data was lost? i was under the impression that verbose gave you MORE data. debug logging is also enabled. ill disable the verbose and run it again.
where do i go to get the XML? all of the help documents just point me to the text file in the user directory.
The bit rate of the failing file is ~68 Mbps while the bit rate of the one which can be processed is ~43 Mbps.
The one log file you attached shows the second file being played which has a speed of 1.7-2.0x realtime need on average.
rogress=11.9&size=-22&remaining=1886&vdec_packets=51&vdec_sw_ok=33&speed=1.9&vdec_hw_status=0 (18 live) Signed-in Token (gsrcrxsi)
Nov 25, 2017 20:30:08.365 [8388] DEBUG - Completed: [127.0.0.1:50239] 206 PUT /video/:/transcode/session/e89c5da77349c823-com-plexapp-android/67e52234-869a-450d-9303-14be491d3fe2/progress?progress=11.9&size=-22&remaining=1886&vdec_packets=51&vdec_sw_ok=33&speed=1.9&vdec_hw_status=0 (18 live) 1ms 326 bytes
Nov 25, 2017 20:30:08.885 [12696] DEBUG - Request: [127.0.0.1:50240 (Loopback)] PUT /video/:/transcode/session/e89c5da77349c823-com-plexapp-android/67e52234-869a-450d-9303-14be491d3fe2/progress?progress=11.9&size=-22&remaining=4009&vdec_packets=72&vdec_sw_ok=54&speed=1.7&vdec_hw_status=0 (18 live) Signed-in Token (gsrcrxsi)
Nov 25, 2017 20:30:08.885 [8388] DEBUG - Completed: [127.0.0.1:50240] 206 PUT /video/:/transcode/session/e89c5da77349c823-com-plexapp-android/67e52234-869a-450d-9303-14be491d3fe2/progress?progress=11.9&size=-22&remaining=4009&vdec_packets=72&vdec_sw_ok=54&speed=1.7&vdec_hw_status=0 (18 live) 1ms 326 bytes
Nov 25, 2017 20:30:09.405 [4260] DEBUG - Request: [127.0.0.1:50242 (Loopback)] PUT /video/:/transcode/session/e89c5da77349c823-com-plexapp-android/67e52234-869a-450d-9303-14be491d3fe2/progress?progress=11.9&size=-22&remaining=3931&vdec_packets=96&vdec_sw_ok=78&speed=2.0&vdec_hw_status=0 (18 live) Signed-in Token (gsrcrxsi)
Nov 25, 2017 20:30:09.415 [8388] DEBUG - Completed: [127.0.0.1:50242] 206 PUT /video/:/transcode/session/e89c5da77349c823-com-plexapp-android/67e52234-869a-450d-9303-14be491d3fe2/progress?progress=11.9&size=-22&remaining=3931&vdec_packets=96&vdec_sw_ok=78&speed=2.0&vdec_hw_status=0 (18 live) 0ms 326 bytes
Nov 25, 2017 20:30:09.505 [12696] DEBUG - Request: [127.0.0.1:50243 (Loopback)] GET /servers (18 live) GZIP Signed-in Token (gsrcrxsi)
Nov 25, 2017 20:30:09.505 [8388] DEBUG - Completed: [127.0.0.1:50243] 200 GET /servers (18 live) GZIP 1ms 494 bytes
Given this data, without collaboration of the transcoding speed (which you can extract yourself by searching for speed=) concludes the first (Bad) file has exceeded the max bitrate the CPU is able to transcode at. The bit rate increase from this successful file to the one which fails is nearly 50%. This is substantial.
what causes the bottleneck where you run into bitrate issues? purely the CPU? honestly with the CPU being underutilized (~30% total usage), I feel like the bottlneck is something else in the system. SSD? im using an old intel 320 series sata2 drive. Memory? its DDR3-1333.
i’m about to test the 100Mbps 4k jellyfish file to see if i get the same behavior.
I have another 4k title thats listed about 83Mbps, and while it does buffer a little, its not NEARLY as bad as the one in question. this 83Mbps file will play and buffer ever minute or so. the bad file is buffering from the very beginning every few seconds. perhaps its an issue of variable bitrate, with the bad file having a consistenly high bitrate, but the decent files only have short periods of high bitrate.
i’ve yet to find a bitrate analyzer that gives me a timebased graphical output that supports hevc. if you know one, please post it. i’d like to see bitrate throughout the file, not just average.
so i dont think the bitrate alone is the issue, but maybe a contributing factor. the CPU is able to have high useage and successfully process a 120Mbps stream, whats happening to the 68 one?
i dont mind getting you more data or trying test cases, just tell me what you’d like me to test.
I’m seeing multiple different “tests” possibly being done in this thread. apples and oranges.
There are many things working here.
HEVC won’t scale out to use all possible cores. It will only use as many as it can. The speed of the core itself is important. So in looking at performance use passmark single core benchmark to get an idea. Some of the advanced codecs do much better with high speed cores.
If using jelly fish sample files make sure to pull down the 10 bit HVEC ones and not the 8 bit files as that makes a difference.
One of the things you need to keep in mind, is some clients that can direct play HEVC may have a problem if you can’t play the audio track. If plex can’t allow the client to direct play the file it may need to use the HLS or DASH protocol. If this happens then Plex will have to transcode both the audio and the video since it will need H.264.
I just took a quick look at your logs and pretty much agree with what Chuck stated above. I would have said the same thing after looking at them.
The best tip I would give you is either upgrade the Plex server to a modern system featuring QuickSync with H.265 support OR stop using H.265 files expecting them to transcode in real time.
If you are running under windows another possibility would be to add an AMD or Nvidia GPU that supports H.265. That would help you get by on your older computer. But unless you can get a deal on one cheap or have on available I’d spend the money on a proper upgrade first.
