I ended up picking up a used server off Amazon Renewed - it has dual Xeons totaling 56 cores. When I look at task manager, the usage during encodes is quite low, even when set to high-priority. Is there an additional parameter I need to pass to Handbrake to take advantage of extra cores?
Thanks! Will.
Are you using hardware encoding? In which case the limiting factor maybe your graphics card and not the cpu.
I explicitly turned off hardware encoding - I’m using an RTX A4000 card in it for Blue Iris videostream encode / decode - that keeps it pretty well tasked. I tried using the system settings to explicitly only use 30 cores - we’ll see if that does anything.
Sadly, no joy. I backed out the explicit core selection and set it to high priority - still relatively low processor usage during encodes.
I did some digging on the handbrake site - there doesn’t appear to be any option to specify the number of threads it can use unless I’m missing something. Will dig into FFMPEG next.
Thanks! Will.
I manually set the FFMPEG profile to use 50 cores - that resulted in slightly higher CPU utilization, but slower conversion time.
I’m trying upgrading the Handbrake CLI to 1.51 to see if that changes the utilization at all. I’ve also set the temp directory to a local SSD vs the network share to make sure that’s not the bottleneck.
If I’m feeling really ambitious, I’ll see what I can get out of PerfMon. Thanks! Will.
The CPU utilization hasn’t budged, but Handbrake is definitely a lot faster than FFMPEG for CPU based encodes. I’ve upgraded to the latest 2.8x stable build of FFMPEG and 1.51 of Handbrake CLI.
Unfortunately it’s not as straight forward as it depends on other factors.
Each encoding profile can broken down into multiple actions, decoding, transcoding or recoding, filters (cropping, interlacing, scaling, noise etc).
All hardware (and underlying software) may not support all operations. So some pieces may be done by hardware and others by software. When this happens there’s also a component of communication and transfer of data between the cpu, memory, graphics cards on the data bus. Depending on how the operations are conducted and sequenced the data may go back n forth on the bus for a single operation or maybe conducted by only the graphics card or only the cpu or a combination.
Hence you’ll see that it isn’t just about how many cores but rather what operations needs to be conducted and by whom and where those operations are being conducted. If handbrake is able to reduce the number of times data flows back n forth between the cpu and GPU that could explain why it’s performing better than ffmpeg.
It could also be the filters for different for handbrake and ffmpeg profiles. We try to keep them similar but there are always minor differences in how each software implements a filter. Some may be able to offload it to the GPU, others may not, others may mix the GPU and cpu for a single operation which may make it even slower than just a cpu based operation as the data spends time on the bus traveling back n forth.
There are some operations (like decoding) which are often more efficient on newer cpus as the time it takes to transfer the data to the GPU and back has a higher latency then the time the cpu would take to compete the operation.
When using so many cores it best to see how to break up operations separately for cpu and GPU and I believe that ffmpeg allows you to do that when creating a completely custom command line argument. You’ll also need in-depth information on your GPU capabilities to optimize it.
