Encoding 8-bit video at 8/10/12-bit in Handbrake (x264/x265)
Comparison Tool with Examples
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
- Pick a bunch of stuff from the left and right sides.
- Hit the big red Show Changes button.
- Scroll down to select and compare the images!
- (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).
Please be patient!
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.
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:
- 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.
- 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.
- 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).
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.
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.thank you for this reference material.
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.
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.
https://mattgadient.com/in-depth-look-at-de-noising-in-handbrake-with-imagevideo-examples/
- 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.
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
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.
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 !!
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?
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.
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?
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.