x265 Versus x264 And CPU Utilization
The idea is that HEVC should allow you to encode video at similar quality levels and lower bit rates. MulticoreWare is currently estimating 25 to 35% lower bit rates at a given PSNR. However, its developers are also adamant that as they add those aforementioned features, encoding efficiency will improve.
With that in mind, let’s take a quick peek at how pre-alpha x265 stacks up against the well-optimized x264. For this one, we're using the following command: x264 --preset placebo --sar 1920:1080 --fps 24 --frames 500 --psnr -o x264Kimonoq24.264 Kimono1_1920x1080_24.yuv, again with quantization parameters between 24 and 42. We could have used the --tune psnr switch to generate higher values, though this negatively affects subjective quality compared to the settings used here.
At each point on the curve, you can either get better quality for a given bit rate from x265, or the same quality at a lower bit rate.
Our test workload, encoded by x264
Same workload with GOP-level parallelism enabled in x265
We know that other HEVC encoders will emerge, and our benchmark suite will likely evolve to phase out the several H.264-based tests as this happens. But more immediately, we’re excited to have x265 as the first in our test lab, taxing high-end hardware more intensively than most of the other metrics we use. In fact, I screen-capped both workloads in action and consistently saw x265 pegging our Haswell-based test mule at 100% utilization, while x264 bounced around quite a bit more.
By the time you read this, MulticoreWare should have more information up at x265.org.