Tuesday, April 22, 2014

A Brief Look at x265 vs x264

The next-gen open-source video codec known as x265 (h.265 / HEVC) is starting to gain some traction, since it is now included in the popular FFmpeg utility and its various derivatives, so I figured I'd do some poking around and see how it compares with the ubiquitous x264 (h.264 / AVC). NOTE: x265 is still extremely new and unoptimized, while x264 is mature and stable, so this isn't really a fair fight just yet.

For this comparison, I downscaled a 720p video to 480p with both codecs. For x264, I used a CRF value of 21, high profile, 'medium' quality preset with a 'film' tuning (these settings were chose for simplicity rather than quality). For x265, I used an RF value of 21, 'medium' quality preset with 'ssim' tuning.

During the encoding, x264 used all 8 of my AMD Bulldozer cores at approximately 95% utilization, with an average encoding speed of ~75 fps. In comparison, x265 reached only approx. 65% CPU utilization, with an average encoding speed of just 12 fps.

As expected, the videos were comparable in quality, with a slight edge going to x264 (maybe related to differences in my settings, or maybe differences in the codecs, themselves; I'm not sure and didn't delve deep enough to find out), as you can see in these sample shots (click for full size, which is still pretty small):
However, underlying that slightly better quality, x264 used roughly 47% more bits per second to encode. That is, x265 had a final bitrate of 624 kbps vs x264's 919 kbps.

So, x265 already produces a significantly more efficient encoding than x264 but the processing power required for that encoding is much greater (roughly one-sixth the framerate). Moreover, decoding is all done on the CPU right now, as no GPUs have built-in decoder chips for h.265, so that means greater power usage and shorter battery life when viewing.

x265 is already impressive in efficiency but the drawbacks of increased computational costs in both encoding and decoding and drastically slower encoding speeds make it currently unattractive to me. I'll be keeping a close eye on development, though, since it's only a matter of time before the tradeoffs are corrected (improvements in the codec), negated (implementation of hardware encoding/decoding) or rendered moot (improvements in general computation power). After all, it wasn't so long ago that x264 was considered immature, unoptimized and poorly supported in hardware vs xvid / ASP. ;)


Charles Nadolski said...

Try encoding x265 without the SSIM preset, and you'll get a much faster encode. That preset is only useful to get metadata about the encode, it doesn't actually have an impact on image quality. Try running your test again and you might be better satisfied with the results.

Anonymous said...

Or trying the lossless mode.

For the time being, If you like the highest quality and high speed encoding. You will need to split many pieces in order to speed up.

There are some methods which has been running on openCL 1.1 supported hardwares which saves some resources until more popularity.

Analytics Tracking Footer