I would prefer to keep transcoding to CPU. quality IS different when you get into hardware encodes. the plex documentation even clearly states this.
I dont think the statement that HEVC cant use all cores is correct. the files that are working correctly ARE using all cores. so how do you rectify this against your statement? the files that aren’t playing as nicely are also using all cores, but with a lower usage on each core.
the problem cant be inherently because of HEVC. i can certainly transcode some of my HEVC 4k files in faster than real time i’ve already demonstrated this. hell, even a rather intense 120Mbps HEVC file went fine.
I do think something else is going on. your thoughts on the audio component are interesting. but at the moment i am not trying to direct play anything. I’m playing to a 1080p screen, so 4k content is forced to transcode regardless.
just played a 140Mbps and a 200Mbps HEVC file. the 140Mbps file even had TrueHD audio. 30 second samples on all these jellyfish vids. and yes of course im using the 10-bt files
both files used roughly 80% of my CPU power.
the 140Mbps file transcoded at just faster than real time.
the 200 Mbps did transcode a bit slower, and hit one section of buffering.
so at some point bitrate can be a limit for my system, but it doesnt appear to be <100Mbps with HEVC.
i also tried the 200Mbps file in H264. performance is certainly better there. but its a given since it’s an easier codec for the CPU to handle. CPU usage about the same 80-85%.
so lets try to narrow down whats hanging up my ~68Mbps HEVC file. it’s not HDR either, as can be seen in the XML.
You must have me confused with someone else. This is the first and only thread I’ve made on this forum. Not sure what you’re referring to with ffmpeg?
I feel like you’re hung up on cpu speed. I’m not sure why. I have other HEVC files using 80% of the CPU. Roughly 80% usage on ALL 20 THREADS. Those files are playing fine. The problem file is only hitting 30% useage. Again on ALL 20 threads. It’s not maxing out 1-2 threads here. The problem isn’t multithread. HEVC CAN AND DOES use multiple threads. You keep putting the blame on HEVC, but ignoring all of the success I’m having with other identically encoded files…
My symptoms point towards a bottleneck somewhere else. We just have to find it. I’m currently running a re-encode of the problem file through handbrake. Encoding it as 264 with very high quality settings (projected 12hr encode time LOL). But I fear that it will still significantly reduce the bitrate to a level that it’s not a conclusive test. There is definitely something different with this file. And it’s not as simple as bitrate if I can smoothly play a 140Mbps file in the same encoding…
The extra power will still be useful for other things I will be using it for. The new system will be rebuilt on freenas11 and running Plex on that. I’m willing to bet all these problems just go away with a different install and we never figure out the true cause.
so i tried something. and i’m not sure if it means anything but i did it anyway.
i took my 68Mbps HEVC file and re-encoded it to H264 at a similar bitrate (68.5Mbps) with Handbrake. Plex actually reports it as 72Mbps but whatever. the file went from about 50GB to 54GB. i somewhat expected this
the H264 file plays much better. this also wasn’t that unexpected since H264 is inherently easier on the CPU. maybe i’m comparing apples to oranges.
another thing i did was since i had this file now in H264, i ran it through bitrateviewer so i can see the bitrate over time, and not just the average.
I moved my whole system over to running FreeNAS 11 with data stored locally and now 2x E5-2680v2 processors and 48GB ram. as i predicted, system runs great, and no files lag on transcoding anymore. i even transcoded 2 4k files, one to my tv one to my phone at same time and nothing unexpected and about 50% total CPU usage. its all working great now.
but once i add subtitles it all goes wrong again. CPU usage gets cut in half playing the same exact file and it starts buffering and saying the server isnt powerful enough. its the same file the server was just playing with more than enough CPU headroom.
seems to me that the server just isnt using the CPU well enough. this isnt an HEVC or H264 issue as it happens with BOTH file formats.
i’m aware that adding a subtitle requires the track to be burned in, and hence is asking the server to do more work, but why then is the CPU usage going DOWN??? i dont care if the cpu goes up, i have more than enough headroom for it.
seriously I was playing my same problem file, coverted to h264 which plays great and transcodes fast. ~35% CPU utilization (effective 70% with single CPU), but when I enable subs, CPU usage DROPS to 10% and the server is now transcoding very slow.
well it seems the problem is PGS subs forcing the whole transcode to be single threaded. and I’m only doing as well as i am because i have 2x CPUs so i can use 2 threads YAY! sarcasm.
people had this problem dating back to 2013/2014. and it’s still not fixed?
Encoding PGS subs is a single-threaded operation. There is no ‘fix’.
while (injecting_subtitles) {
read(subtitle);
wait_for(subtitle.timestamp);
while (subtitle.duration) {
GetFrame(image)
BurnIntoImage(image, subtitle.text);
SendFrame(image);
}
}
Each frame must be read and decoded in sequence, the subtitle text burned in, then output frame placed in the output stream buffer and multiplexed with the audio.
wait_for() sits in its thread and waits (blocks) until the needed frame timestamp is encountered in the input stream. When encountered, it locks the frame and does its thing. When done, it releases the frame back into the wild.
If I may playfully share some return sarcasm ?
“If you think it’s easy to do, would you like to help create a new way to perform video transcoding and subtitle burning ?”
the behavior on my system does seem to fit with the single threaded nature. but the burn in process itself cant be that intensive. i just find it hard to believe that its not possible to get the heavy work done transcoding first then simply add the subs. I mean handbrake seems to be able to do it and its highly threaded. so whats different?
now lets look at this another way. you’ll say i need more clock speed, and cores don’t matter. it’s a single threaded operation after all right? so i loaded up PMS 1.10 on my gaming computer.
5.0GHz i7-7700k 4c/8t
gtx 1080 (not that it matters, i dont think gpu accel is on by default is it?)
win10pro
loaded up my 4k movie, transcode to 1080p+ pgs subs.
STILL couldnt handle it (albeit better than before). CPU usage dropped from 100% (when subs were off) to ~70% when subs were on. i’ll be honest that i expected the CPU to drop to less than 20% since i expected it to revert to completely single thread.
can you explain this behavior? if it’s only single threaded with pgs subs on, why am i using all 8 threads at 70% utilization.
secondly, if we only need clock speed, is 5.0GHz really not enough to handle adding pgs subtitles to a 4k transcoded movie? i havent seen many people capable of more than 5.2-5.3GHz on real rigs without some extreme measures. something just seems terribly inefficient if the software needs such unrealistic hardware specs to run properly. is there any CPU capable of doing what I’m asking? (4k HEVC transcoded with PGS subs)
or is hardware acceleration NECESSARY at this point? let me know your thoughts.
The fundamental problem is the HEVC codec itself. It is not yet optimized, and may never be, for full multi-threaded operation. It was created for embedded hardware decoding only (set top box operation).
The 7700 series CPUs (those with HD 6xx series GPU) are the first to be able to perform this in a desktop.
You are expecting hardware decode of HEVC, hardware addition of the PGS subtitle, and then hardware encode to H.264 in this first generation CPU to handle HEVC. Just because the CPU is showing 20% utilization does not mean the GPU isn’t fully saturated.
There is an Intel utility which displays GPU utilization. In Linux it is intel_gpu_top. It shows everything happening in the GPU. I recommend you obtain the Windows version.
To answer your question: Your own numbers indicate HW transcoding is necessary. 100% CPU. I cannot quantify your expectation as I know how demanding the HEVC is of the hardware but do not know the Windows platform and what their display architecture may add or detract.
As comparison. Use purely a player program such as VLC. The load it places on your resources is the same load will be the same PMS uses in the Decode phase. It is the same because once the frame is decoded, spitting the bits on the display window is so trivial (directly deposited in the display buffer) it is below measure.
Chuck I think you’re getting a bit confused (or maybe havent read all my posts) about some of my details
This 5.0GHz 7700k rig was only a test. it is not my main server. its only a quad core. i saw 100% CPU utilization while simply transcoding a 4k HEVC title. then it dropped to 70% when i enabled the subs. but if burning in PGS subs is single threaded, why didnt the CPU drop down to 25% or so? if im showing 70% CPU it HAS to be using at least 3/4 cores. that doesnt sound single threaded to me. do you see my confusion?
my main server is 2x E5-2680v2. total of 20 cores and 40 threads. can boost to 3.6 GHz if one core is in use, and only 3.1GHz if all cores are active. this system is running Plex via a plugin/Jail in FreeNAS 11.0
now the problem with subtitles isnt solely limited to HEVC titles. I see the same exact thing on H264 titles. once i enable PGS subs, the CPU usage drops and the system struggles. again, this is BOTH H264 and HEVC. so you’re saying theres no system that can handle a 4k transcode with PGS subs on CPU power alone?
CPU utilization changed because it became even more single threaded. That’s what happens.
FWIW, PGS subtitles are VERY demanding regardless what you’re using for equipment. PGS subtitles were created solely for the player because the player has multiple video display planes in hardware. Text is rendered on the first plane, image on the background plane, During scan-out they are OR’d together to form the image.
Yes, that is precisely what I am saying. You’re not going to find a machine which can do 4K HEVC and PGS subtitles in CPU.
Maybe when the Gemini Lake and/or i9 CPU is available you might see it but it’s entirely unknown until Intel delivers and folks have time to benchmark.
i guess the only real solution right now is to pre-process all of my 4k files using handbrake to burn in pgs subs (forced for mostly english content) or add SRT external files.
im not sure i understand the usage. i’ve never used ffmpeg standalone, only when it was being used by another more user friendly program on the surface (like handbrake). how exactly do you use ffmpeg by itself? is it CLI only?
that link says you can do the same thing with PGS if im reading it correctly? that way i dont have to fiddle with trying to find the right srt file and splicing it in, just use what’s already in the video file, right?
i assume you install ffmpeg, navigate to the directory with the input file, run ffmpeg command with options (are other options necessary if all im doing is the subs?) and list the output filename. and the output file goes to the same directory?
