Encoding 8-bit video at 8/10/12-bit in Handbrake (x264/x265)

Star Wars: The Force Awakens

Warning: 48-bit PNG images on this page (using this tool) can be very bandwidth intensive. Some images are over 8 MB. If you select ALL images for comparison (9 checkboxes) that could be up to 150 MB just for that single comparison.

If your internet provider has restrictive data caps, you should be very careful about using this tool.

Notice: This set of test encodes was done over the course of a few months in 2017 before being published in Jan 2018. Newer versions of x264/x265 may exhibit different behavior. Always run your own short test encodes (at least 10-30 seconds) to ensure you're happy with the result before hunkering down to do a long encode.

Instructions

This section lets you see the results of 2 encodes, side-by-side. It basically works like this:

  1. Pick a bunch of stuff from the left and right sides.
  2. Hit the big red Show Changes button.
  3. Scroll down to select and compare the images!
  4. (optional)
    • Use the Blue Buttons to choose between shrinking fit your screen, showing side-by-side, and showing the full resolution image (with scrollbars if it's too big to fit your screen).
    • There is also an Auto Update button you can use if you're tired of clicking the red Show Changes button each time you make a change.
Warning: If you haven't used the tool before you should scroll waaaay down and read about some of the details, caveats, and gotchas before relying on the results!
Loading comparison interface...
Please be patient!
Optimized images (smaller file size, but may have alternate color profile)

Usage: A Quick Primer

By default, an x265 (HEVC) 8 vs 10-bit comparison is selected, at 400kbps and an encoding preset speed of "Slow".

Clicking the various options will let you see the output of the selected settings. For example, if you want to see the difference at insanely low bitrates, you might select a bitrate of 50 on each side, then hit the Show Changes button to see the images.

If instead you want to see the difference at a certain RF value, you might choose RF and then select... say... 22. Note that when using RF, you should keep an eye on the Video_Clip_Size mentioned in the details because it will often differ, sometimes substantially, since RF doesn't aim for a specific bitrate. If one video has a much higher bitrate than another but all else is equal, it stands to reason that the video with the larger bitrate will look better.

Because the default display (side-by-side, shrink to fit) might be too small to see differences in detail, playing with the Blue Buttons to change the layout can be helpful.

Why?

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 and 3 tune settings are available. 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.
  • While SSIM and PSNR are a couple of the tune options, I don't have the ratios saved/displayed. Originally I was going to go that route, but haven't followed through for a few reasons.
  • 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.

Note: This page is a Beta

Like the previous encoder comparison (x264/x265/VP8/VP9), this one is also something of a "beta". Depending on traffic and interest, it could be expanded on, or could go down completely at some point. Few main items that have a bearing here:

  1. The images just for THIS PAGE are a whopping 44 GB. For reference, the entirety of mattgadient.com is about 1 GB if you exclude my encode comparison pages.
  2. These are really time consuming to process (encode, generate screenshots, etc) and put together a custom page for. The encodes alone took 998 hours, 56 minutes, 46 seconds. Add a number of hours for image generation, modifying the tool, uploading and we're well past 1000 hours. I don't want to spend weeks putting these things together if it's not something that a number of people would find helpful/useful.
  3. This page is insanely bandwidth-intensive for visitors. Unlike the write-ups on this site (which even dial-up can handle), only those with really fast unlimited connections are going to be able to do a lot of comparisons with this tool.

If you feel strongly one way or another (really like this page or could do without it for example), please leave a comment. It would also be helpful to know what in particular you were interested in (Encode time differences between 8/10/12-bit? Seeing visual differences? Something else...?). Thanks!

Legal

Contains content from Star Wars: The Force Awakens ( © & ™ Lucasfilm Ltd.)
This content has been legally used on this site, pursuant to Section 29.0 of the Canadian Copyright Act (Royal Assent June 29/2012, Effective Nov 7/2012).