2024 Cross Platform Handbrake Benchmark

      This is a small update to the previous 2016 benchmark to include a new generation of small ARM boards. This also moves the benchmark to using the modern *.json based HandbrakeCLI and moves to using "constant quality" instead of the average bitrate settings in h.264, as recommended by the developer. As such, the improvement in slower encode time results in smaller videos, not higher quality. One major flaw at the moment is the lask of a standard desktop computer to baseline performance. While it still runs all the games I want to play, an i5-4670K is quite old now.

      The Handbrake benchmark uses custom compiled code for all Linux platforms. The only pre-compiled code was on Windows for the i5-4300U and i5-4670K.

The Players
      Raspberry Pi-2 (quad-core ARM A7 0.9GHz) - Raspbian
      Raspberry Pi-3 with heatsink (quad-core ARM A53 1.2GHz) - Raspbian
      Raspberry Pi-4 with heatsink (quad-core ARM A72 1.5GHz) - Raspbian
      Penguin Computing Valkre 2012 (48-core Cavium ThunderX ARM 2.0GHz) - Ubuntu
      nVidia Jetson Nano (quad-core ARM A57 1.43GHz) - Ubuntu
      Odroid HC4 (quad-core ARM A55 1.8GHz) - Ubuntu Mate
      Odroid N2 (quad-core ARM A73, dual ARM A53 2.4GHz/2.0GHz) - Ubuntu Mate
      Core-i3 5010U - dual-core 2.10GHz - Ubuntu
      Core-i5 4300U - dual-core 1.9GHz/2.9GHz - Windows 10
      Core-i5 4670K - dual-core 3.4GHz/3.8GHz - Windows 10

      Handbrake command used (with variations on path to the source and save location):

      HandBrakeCLI --queue-import-file TearsToTiaraBenchQueue

      with being the Ultrafast/Veryfase/Faster/Fast/Medium/Slow/Slower/Veryslow/Placebo seen on the chart.
      Here is a link to a sample *.json file for an example of the parameters used: Download json

      Note 1: As the motion estimation quality increases, the RAM required by Handbrake also increases. Systems with only 1GB of RAM were unable to complete the task beyond the 'medium' setting. 2GB RAM might push that to 'slow'. With storage space as cheap as it is now, for nearly all users, 'slow' would be fine. That said, 'veryslow' does result in the best output size. (The developer recommends against using placebo, and it does, indeed, not give the best result)

      Note 2: As the compiles for the Jeston Nano with, and without nvenc gave the same resulting times, I am quite certain it was either on or off for both (probably on), and only one was included.

      Note 3: While Handbrake does scale up to about 20 cores in constant quality mode, it does not scale farther. The ThunderX is able to encode 2 videos simultaniously in the same time it takes to encode one. Encoding 3 only slows it down a bit. Not going to win any records now, but I did buy it eight years ago.

Handbrake Encode Speeds in 2024

Main Page