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

Comparison Tool with Examples

April 30, 2020: It took over a week (sorry - slow connection), but all images should be back up. If any are broken please leave a comment.

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 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.

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 about 14 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).

22 Comments | Leave a Comment

 Sort by Oldest | Sort by Newest
  1. Nikhil N. on February 6, 2018 - click here to reply
    Hi Matt,

    Great selection of of shots for comparison. I am noticing a lot of pixellation in the images on the 10-bit ones. I don't think that's quite right since going from 8-bit to 10-bit should reduce this banding effect. I suppose this has something to do with browsers showing images.

    I'm using Safari Technology Preview R48. Chrome 64 yields the same. I'm on macOS 10.13.3.

    Can you suggest an alternative so I can view them properly or feel free to point out any mistake I may be making. Here are the settings I'm using: https://dsh.re/380b3

    Cheers.
    • Matt Gadient on February 6, 2018 - click here to reply
      Not positive here - this tool has a little more of a "here is some data, draw your own conclusions" aspect to it. This is partly because differences aren't always easy to quantify and partly because I'm not on high quality production level equipment myself... my Intel HD graphics + Samsung TV might show quite a bit differently than someone with a workstation AMD/nV card on a proper high end pro display.

      With that in mind, a few possibilities off the top of my head:
      • What you're seeing could actually be the result of this 8-bit video being encoded at 10-bit through Handbrake (ie no technical issue). In which case, encoding at 10-bit maybe has some downsides here.
      • You mentioned in another comment you're on a Hackintosh - while I *think* true Macs handle 10-bit, depending on your monitor you could be in a situation where you've got a more common 8-bit monitor trying to approximate 10-bit. It may not do this in a way that looks great (may just flicker pixels between the nearest 2 8-bit values).
      • As for software (if it's a web browser thing), I don't have any fancy deterrents in place to make it a hassle if you want to save an image, so you should be able to just right-click-save-as a few of these images and try opening them in a high-end image editing program that supports high color depths (likely Photoshop etc).
      • There's always the possibility that I screwed up something on my end during the image generation and didn't notice. It would have been nice if I could have integrated the videos (not just images since that adds another variable due to color profiles etc), but since browser and OS support for HEVC is so minimal due to the screwed up HEVC patent situation, I didn't go that route here.
      Anyway, hopefully a few others can chime in at some point with what they're seeing (and maybe what equipment they're on). If everyone sees the same thing you do, then it could be as simple as 8-bit encoding at 10-bit not being a great idea (or me having messed up somewhere). On the other hand, if people are seeing different things, we can hopefully get a sense as to what the weak links tend to be in hardware/software.
  2. Anonymous on May 3, 2018 - click here to reply
    nice work, man.
    thank you for this reference material.
  3. Lodhar on May 25, 2018 - click here to reply
    This test is awesome! You made my day, thank you. Did you program all that by yourself? Or did you use a tool, or a library? Well, I did learnt a lot today.
    • Glad you found it useful! As for the tool, for the encodes themselves I used the Handbrake CLI - I wrote a script that iterated through all the (shown) options, doing encodes for each combination of options via Handbrake and then generating screenshots (ie extracting single frames) from those video clips via ffmpeg. I don't recall what I used for color counts, but it might have been identify. For the website/display end of things, I wrote a pile of javascript.
  4. quovadis67 on July 2, 2018 - click here to reply
    Hi. I have been doing my own encodes for a few years but don't have a deep technical understanding related to the intricacies of video formats and encoding methods etc. In an effort to improve my uinderstanding I wonder if I could make a few assertions I believe to be true, and if not maybe you can correct/improve my understanding?

    1) Traditional HD Blu Ray x264 encodes have a native bit depth of 8 bits (24 bits per pixel)
    2) x265 10 bit encodes of 8 bit sources have value because they (a) can produce a smaller output file and (b) reduce banding because high-bandwidth differing is not needed to simulate colours beyond 8 bits (which seems to imply this is what the source x264 material does).
    3) A 10 bit encode may be limited visually by the playback path, eg. via a HTPC that only passes an 8 bit colour to your TV or the TV itself only able to handle 8 bit colour depth

    For the record I have started doing my encodes using x265 10 bit via handbrake but just wanted to confirm my understanding of why I'm doing it is actually correct.
    • 1) Yes.

      2) Possibly and possibly. In theory I believe it's supposed to work that way, but in practice it's hard to say. Storing more data (color values) would obviously tend to increase bitrate. But high frequency dithering takes enormous bitrate. So assuming the encoder takes some of that high frequency dithering and smooths it out into something resembling static colors in the 10-bit spectrum, you'd have a more efficient use of bitrate: storing the extra colors instead of tonnes of dithering. Where the allowed bitrate wasn't high enough to store all the dithering, the obvious side effect would be a reduction in banding since you've got that larger spectrum of colors to smooth that dithering into. But again, this is all in theory and depends on encoder behavior, the source, etc. To verify the behavior you'd have to do a lot of A-B testing.

      3) Yes. A number of laptops (including the one I'm on now) actually have a 6-bit display. How this is dealt with depends on the device. Output could be dithered, rounded, or something else.
      • Quovadis67 on July 2, 2018 - click here to reply
        Thankyou very much for your prompt reply, and it is good to get some confirmation and clarification of my current understandings in this area. Cheers.
  5. Anonymous on July 25, 2018 - click here to reply
    Hi, can you please update your article about denoising about the new NLMeans hqdn3d and also the new custom setting for both?
    https://mattgadient.com/in-depth-look-at-de-noising-in-handbrake-with-imagevideo-examples/
  6. Anonymous on July 31, 2018 - click here to reply
    My 12-bit encodes have smaller file sizes than both the 10-bit and 8-bit, while the 10-bit has smaller file size than the 8-bit, all at the same settings using H265 RF18 at placebo. Getting different results from yours.
    • Quite interesting. Couple possibilities off the top of my head:
      • Newer versions of x264/x265 will undoubtedly behave differently (x265 has made some pretty substantial changes over time that resulted in encode at RF X having different results depending on version though I don't know whether anything specifically applied to 8 v 10 v 12-bit behavior). While I published this in January/2018, I had started this months before. The encodes alone took over 40 days and between crashes, power outages, and other stuff going on the entire process was over the course of a few months. So we're probably looking at my results being around a year old now.
      • Other sources may obviously behave differently from this source (assuming you didn't reproduce this source via the time stamps I listed).
      Neither is easy to verify without reproducing the encode unfortunately. I do have the original buried somewhere - if I come across it at some point I might do a couple quick tests to see where the results sit.

      For now I'll put up a notice indicating the encodes were done in 2017 and that new versions of the encoder may show different results.

      In any case, thanks for letting me know.
  7. stephan on September 24, 2018 - click here to reply
    HI Matt

    Great site, I really appreciate the work that went into that!

    I currently evaluate to switch from x264 to x265 nd in this test and the previous one from 2016 I noticed how x265 still removes detail even at higher bitrates.

    So you have experience with up-to-date version of x265 and the option "no-sao"? The latter is often mentioned to retain detail instead of "grain" over at doom9 forums since grain introduces grain and no-sao should retain grain

    thx
    stephan
    • Matt Gadient on September 24, 2018 - click here to reply
      Hi stephan,

      I have not done much encoding since this was written, and have not looked at new options like "no-sao". You may want to do a few short test encodes to compare results with and without that option.

      You mentioned you are considering switching from x264 to x265. If you plan to spend time encoding an extremely high number of videos, it's worth keeping in mind that AV1 ( https://en.wikipedia.org/wiki/AV1 ) has been making its way out and is an upcoming possibility. Whether it is worth waiting for AV1 to mature and see if you might prefer it to x265 is something you'd have to decide though. If you're just doing a few videos, probably not a big deal. If you're spending hundreds of hours encoding your entire collection.....might be worth weighing the options.

      I mention it because I have a feeling that within the next few years AV1 will largely supplant x265/HEVC due to the large industry support it has, and the fact that it has avoided the massive patent mess that x265/HEVC created for itself. x265/HEVC will still be around of course (it's used for UHD Bluray and ATSC 3.0 amongst other things), and right now AV1 encodes are pretty time consuming. But other encoders have become quicker as time has gone on, and there's no reason to think the same won't be true for AV1.

      That said, HEVC/x265 is here and "ready" now. It also has a healthy amount of hardware support. There's of course value in that, and sometimes waiting for the upcoming-new-thing becomes a perpetual wait.
  8. Augusto Magana on September 25, 2018 - click here to reply
    Thank you very much, man! Very informative.
  9. Jean-Pierre on October 18, 2018 - click here to reply
    I am sure there is a logical explanation, but I am a bit lost with the " Quality Setting:"...
    If I select in Contender#2 : X265, none, RF22, I have for image 1 and unique colours:
    - placebo : 51 168
    - slow : 50 765
    - faster : 52 105
    - ultrafast : 58 322
    I thought using placebo was giving the highest number of colours, which seemed confirmed by selecting slow (- 403), and the quality had to drop step by step.
    But I got then more colours than with placebo when selecting faster, or ultrafast (+7 154 ) ...

    Would it mean that they are "good" and "bad" colours ? By instance, less "good" colours (from source) when slow vs placebo, but the speed increasing adds "bad" colours than are just noises, echoes and added garbage ?...

    Otherwise, great thanks for the job, very useful !!
    • Matt Gadient on October 18, 2018 - click here to reply
      I'm really not sure. I myself haven't put too much focus on comparing the actual number of colors between each result - I listed them primarily because I thought the data was interesting and I figured maybe others would find it interesting too or might be able to find correlations somewhere.
  10. Pimpampum on February 15, 2019 - click here to reply
    Awesome work, couple of questions:

    Is this not pointless since Handbrake pipeline works internally in 8bits?
    Also, im getting lower file size the faster preset choice i make, ultrafast getting lower file size than placebo?
    Encoding at 10bits will automatically trigger HDR mode on a TV?
    • Matt Gadient on February 15, 2019 - click here to reply
      As to the 8-bit pipeline, it doesn't really matter in this case (originally an 8-bit video being encoded at 10+). The video just stays at 8 bits throughout the pipeline until it hits the encoder where it technically becomes 10-bit. There doesn't appear to be anything in the pipeline after the encoder that clamps it back down to 8 bits. This is a different situation from something that was originally 10-bit (UHD BR etc) which gets gutted down to 8-bits in the pipeline (bad) and will result in a video that has technically has 10-bit color in the end, but not necessarily the original 10-bit colors.

      Whether there's *value* to doing this or not is something left for the viewer to determine. There have been numerous claims (particularly in the anime community) that encoding 8-bit videos at 10-bits reduces banding that can otherwise result in an encode. A paper is floating out there as well that suggests efficiency gains. This page looks at a typical movie so people can determine for themselves what impact(s) and/or tradeoff(s) there are (if any) to encoding 8-bit at 10-bit.

      -
      As to the faster/ultrafast/placebo file size oddities you're seeing, I have a writeup that goes over why that can happen at https://mattgadient.com/handbrake-rf-slower-speeds-craziness/ .

      -
      Finally as to the TV and HDR mode, I really have no idea.
  11. I'm Oily on December 3, 2019 - click here to reply
    Thanks for this. Although including anime would be even better especially for dark scenes, action scenes, scenes with banding, and bright color scene comparisons. Also, HEVC 3.2 has matured greatly since.
  12. David on April 22, 2020 - click here to reply
    =OmG!!!
    INSANE project!
    But very insightful!!
    The sort of thing I'd love on Bluray for archival reference.

    Future tests ought to include something with fine details and text - maybe a magazine/newspaper image - to help discern which settings/formats retain such detail the best.
    Intel Quicksync / Nvidia NVENC GPU accelerated encode comparisons would be useful, too.

    Guess we will be seeing the next version next year when VVC/MPEG-5 is out?
  13. LE GARREC Vincent on August 12, 2020 - click here to reply
    It's really a good idea. This will help me by avoiding doing it on my computer. :)

    I just have a suggestion : you should add an image from a (extreme) moving scene. Usually, these images have lower quality and it's easier to found default / quality lost.
  14. Anonymous on February 15, 2021 - click here to reply
    Do you have an example scene you could pull that includes a bright scene with a sky gradient? Everything here shows the details you can get on dark / average scenes, but the only "sky" in any of these is the neutral color behind Finn and is obscured by smoke.

Leave a Comment

You can use an alias and fake email. However, if you choose to use a real email, "gravatars" are supported. You can check the privacy policy for more details.