Handbrake - CPU Limitations
Results 1 to 1 of 1
  1. #1
    Anime Revolutionist
    LastVanguard's Avatar
    Join Date
    Apr 2015
    Location
    Indiana
    Posts
    370
    Thanks
    60
    Thanked 113 Times in 76 Posts
    Blog Entries
    3

    Default Handbrake - CPU Limitations

    All,

    Since OS uses mostly Handbrake for video encodes for the site, I wanted to share my experiences with it from an engineer's standpoint. This is the perspective of someone who's done 20,000+ encodes using Handbrake, so I know a few tricks of the trade with it.

    Handbrake is a great program in the sense that it's free, and it uses a graphic interface that's pretty easy to understand. After trying Handbrake alongside ffmpeg and other paid-for encoding programs, I keep going back to Handbrake simply for ease of use. However, it has some finite limitations as to what it can do, and how well its performance can scale. The main downside to Handbrake is that it's not as easy to automate encodes in it compared to a utility like ffmpeg.

    Recently, I was given the opportunity to demo Intel's Xeon 2699 v4 processor. This is currently the best processor money can buy (I'm not exaggerating, list price on it is $4,800). 2.2Ghz. 22 cores. 44 threads. The reason I agreed to demo it was because I've been striving for some time to get Handbrake to encode faster, since I've hit a wall where it can't encode a 720p video in under 2.5 minutes, which is too slow for me in the area of batch processing.

    Installing it in my desktop (full specs available on the PC Specs Forum Thread), I found that only actually used 40% of my CPU for Handbrake when it was encoding, even after I manually set the processor affinity (basically, the priority given to the task) to the highest possible. It only used 20 of my CPU threads for encoding, and it didn't even max them out - they mostly stayed around the 70% usage area. Normally, Handbrake completely maxes out all my CPU on the 6-core i7-5930k I normally use. That being said, it could still encode a 720p video in 1.25 minutes, so it was a notable improvement over my existing rig.

    Puzzled by this, I tested ffmpeg against it and basically had the same results. Testing a couple other programs yielded the same thing as well.

    After an extensive amount of digging on the web, I found that video encoding is actually limited by your L3 cache on your CPU more than the amount of cores or GHz of each core. Because I was filling up my L3 cache with encoding instructions, I basically had nowhere else to offload cached instructions to except for my computer's memory, which is nowhere near as fast as the on-die CPU cache. Because of this, I hit a finite limit with what all encoding programs that are designed around this could do. The only way to scale past this point was to either offload encoding functions to more than one GPU on your computer (which is why manufacturers like Dell have built multi-GPU servers specifically for this task), or install a second CPU in your workstation.

    The non-technical explanation for this? Basically, you can only make Handbrake go faster to a certain degree, and then it will hit its limit. Unless you want to load 4 nVidia Tesla cards into your computer or install a pair of $4,800 CPUs, video encoding can only do so much in a desktop environment. The same is going to be true of every type of desktop/workstation encoding program on the market. This is why many of them recommend 2 x 6-10 core Xeons for optimal performance, simply because the software can't scale past that point.

    The moral of the story is that Handbrake is great for desktop-level encoding, but its use pretty much stops there. If you wanted to get into cloud-level hypercomputing for your encodes, you'd need to explore an alternate solution.

    I say this so that a member on OS doesn't go out and buy a 16-core Xeon processor thinking it will greatly speed up their encodes. It won't scale that far. A 10-core probably will, but anything past that is probably unnecessary overkill. My plan is to get a hold of a server that has 4 x 10-core Xeons, because that will give me 80Mb of L3 cache to work with, which might give me some additional performance on my encodes over the 22-core Xeon I've demo'ed. I'm guessing I'll be able to get my 720p encodes under a minute at that point, and that's good enough for me.

    Cheers,
    Caleb (LastVanguard)

    For those that care.. an update to this after I've conducted some additional research.

    I've found the reason why there's such a huge performance gap in encoding times between the CPUs of 5 years ago and the CPUs of today (basically, why a mid-grade CPU today can out-encode a top-of-the-line CPU from 5 years ago even if it has a higher GHz speed, more cores, and if it has a GPU to offload some functions to).

    It's Intel's QSV (Quick Sync Video) technology. AMD has also copied this technology, and calls their version "VCE". It's available on most CPUs made in the last two years.

    While you can read the full Wikipedia spec on this technology here, the basic gist of it is that Intel has built a dedicated chip onto their processors solely for the purpose of doing H.264/H.265 video encoding or decoding, and it drastically speeds up the time it takes to run Handbrake encodes. To give an example, it usually cuts encoding times to about 1/3 or 1/4 of what they would otherwise be.

    I've run several performance tests on a current desktop computer with a mid-grade i7 processor against a top-of-the-line server from 5 years ago with 2x 6-core Xeons and 96GB of RAM. The modern desktop wins by a margin of about 30%, even though the older server is faster on paper, has more than double the CPU threads, and over three times the RAM.

    Basically, if you want to dramatically speed up your Handbrake encodes, it pays dividends to shell out the money for a computer with a CPU produced in the last 2 years. If you're wanting to do some hardcore encoding but had trouble justifying the cost of a new rig, here's your excuse. :)

    Cheers,
    Vanguard
    Last edited by Dudette09; 04-02-2017 at 05:25 PM. Reason: double posts~

  2. The Following 2 Users Say Thank You to LastVanguard For This Useful Post:

    error345 (02-07-2017), FiQ5149 (01-13-2017)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •