Results: Encoding 8-bit Video At 8/10/12-bit In Handbrake (x264/x265)

The main purpose of this page is so you can see for yourself whether or not there might be an advantage to encoding typical 8-bit film as 10/12-bit. Note that you should really attach "...in Handbrake", "...using these versions of x264/x265", and "...using this specific Star Wars movie as source" to that because let's face it... Handbrake may do something differently than Program Y does in it's toolchain, x264/x265 may behave differently from VP8/VP9/AV1 or even other versions of x264/x265, and Source Y may be impacted differently from The Force Awakens. In other words, take these results with a grain of salt!

The secondary purpose of this page is to let you simply see the differences in encode time, behavior at different RF values, etc. Basically the things you can figure out by changing the top buttons (and don't necessarily need the images for).

You will notice that Unique Colors (green bars) is often substantially higher for the 10 and 12 bit encodes. For example, a 10-bit version might show 20x the colors of the 8-bit version. This doesn't mean you'll necessarily see that difference visually. Couple big reasons here:

• Consumer-level support for 10-bit+ color is really minimal. Most consumer grade monitors and displays out there won't do 10 bit. Consumer video card support has also been extremely marginal until recently. So depending on your hardware you might only be seeing 8-bits worth of color (or less... some LCD panels only do 6-bits and may or may not use some trickery to approximate 8-bit).
• The colors "gained" in the above clips are largely going to be due to averaging and/or rounding. To put this into perspective:
  • If you've used an image editing program before, you've probably noticed that each of the RGB (red/green/blue) values tend to go from 0-255. This happens to be the range for 8-bit color (24-bit when you save RGB, or 32-bit when you save RGB and Alpha).
  • Assume the blue value (0-255) was 100. If you increased it to 101 you might notice the difference. But you might not.
  • If you do a small bit of math, 10-bit has 4x the total values of 8-bit. For simplicity, staying with 0-255 we'll say that instead of going up by +1, we can go up by +0.25.
  • Assume the blue value (0-255) was 100. If you increasd it to 100.25 you probably wouldn't notice the difference. Definitely not if you didn't notice the difference between 100 and 101 previously.
  ...if we originally had a scene with 2 blue values (100 and 101), after our 10-bit conversion with some rounding we may have 100, 100.25, 100.5, 100.75, 101. That's quite a bit more colors! And they're so close we might not be able to visually distinguish them! And that's just looking at the blue value! Add red and green (r, g, 100 and r, g, 101) to get a real color and we have even more combinations.

A few other things to note:

• Only 4 speed settings are available and they all utilize Tune: None. Reason is that encode times calculated during the initial test runs were really brutal so I had to make a few cuts. Since I already have full speed/tune settings in the x264 vs x265 vs VP8 vs VP9 comparison page, I didn't feel too bad about removing them here.
• Previously, SSIM and PSNR were listed as alternate tune options, but since I didn't have the ratios saved/displayed (which was the original plan) I didn't bother re-uploading them. To be frank, I suspect that listing them probably confused more people than they helped.
• 1080p refers to the "pre-cropped" version. Once black bars were cropped, the dimensions became 1920x800.
• Bitrate-based encodes all used full 2-pass to try and get the file sizes as exact as possible for fixed-bitrate comparisons between encoders.
• Very low bitrates (50, 100, etc) may result in blank/grey images. This is not a bug: the encoder simply did not have enough bitrate to work with in those situations.