I do a lot of HEVC encoding and what I've read is 10bit is always better than 8bit, even from an 8bit source, because it avoids rounding errors. Is that true?

Also, then is 12bit better than 10bit or are the rounding errors insignificant at that point?

  • 5
    Well, 10-bit has 4 times the resolution of 8-bit, so yes, rounding errors will be smaller. Assuming you are encoding for end use, the benefit will depend on the source material and the display medium. The same is true for 12-bit, in principle, but the extra resolution over 10-bit shouldn't be significant for normal end-use.
    – Gyan
    Apr 19, 2016 at 11:18
  • And it depends on what you mean by better: if you're talking about storage size then 10 bit is 25% worse than 8 bit, and 12 bit is 50% worse. If storage and drive speed is not an issue then obviously throwing more data at it will make the encoding better, but the difference in quality might not match the increase in size.
    – stib
    Apr 27, 2016 at 14:02
  • @stib, Everything I have read suggests the opposite. myanimelist.net/forum/?topicid=358699#msg12115983 gist.github.com/l4n9th4n9/4459997#L37
    – Fallen
    Apr 28, 2016 at 1:39
  • I use 12 bit footage in production, it's huge, but it has the advantage that the video has waaay more latitude for grading: you can pull down over-exposed shots and bring up details in shadows without it all turning to mush, like 8-bit footage does if you push it too hard. However if you aren't going to process the video any more you don't need the extra latitude, especially if the extra info didn't exist in the first place. Sure, 10 or 12 bits will mean less quantisation error but quantisation error is trivial compared to the losses you get in a lossy codec.
    – stib
    Apr 28, 2016 at 4:46
  • Are you sure your not using 12 bit raw vs like 12 bit hevc/x264? Because raw anything is huge.
    – Fallen
    Apr 28, 2016 at 19:49

3 Answers 3


I can answer your first question. At the same bitrate and transcoding from an 8-bit source 10-bit HEVC is better than 8-bit HEVC, because it hardcodes dither. archived version of https://gist.github.com/l4n9th4n9/4459997 I am still unsure, whether that makes 12-bit HEVC transcodes superior to 10-bit, thats why I ended up here.

  • After I ran some tests I have found that 10bit also results in higher file sizes too. I'm curious if the bitrate was raised for the 8bit encode to match the final size of 10bit would it result in the same quality.
    – Fallen
    Jun 20, 2016 at 19:57
  • The reference you linked to seems highly contentious, and there has been no response to the controversies since. Elsewhere on the net there also seems no agreement on this. Jan 9, 2019 at 4:20
  • 1
    To clarify, dithering was added to the 8-bit file resulting in a larger file. The 10-bit file did not require dithering. Obviously if everything else is constant, a 10-bit file will be 25% larger than an 8-bit file, but the consensus is that a lower file size for the same quality can be achieved with 10-bit.
    – pyrocrasty
    Oct 29, 2021 at 4:44

In my experience (using handbrake) increasing the bit depth increases the file size but not by much. However, lowering the CRF is what causes significantly larger files. I encoded several times the same source with different settings to see what I'd get, so for a random source of 1.45Gb (H.264/AVC) it gave theses results:

  • H.265 8bit CRF 22 (slow) > 362.6 Mb
  • H.265 10bit CRF 22 (slow) > 385,2 Mb
  • H.265 12bit CRF 22 (slow) > 390,7 Mb
  • H.265 8bit CRF 20 (slow) > 470.2 Mb
  • H.265 10bit CRF 20 (slow) > 509,9 Mb
  • H.265 12bit CRF 20 (slow) > 518,9 Mb

Hope that helps.


I've been running some tests lately (2H2020) concerning reducing the size of some high quality movies of my collection, just for PC to TV 1080p viewing, from 20-30mbps videos to 2-3mbps ones. To that end, I run some ffmpeg (latest gyan.dev version at the time) tests comparing same-bitrate encodes between: codecs (x264,x265,VP9,AV1), presets (slow, slower etc), CRF's (21,22,23,24 etc) and encoding colorspace (8bit, 10bit, 12bit), where applicable. I have arrived at the following combination as my personal preference:

• x265. This is always better than x264 bitwise. It's also worse than aom-av1, but aom-av1 is not optimized to work on all CPU cores, therefore aom-av1 is time-expensive in the end. Unless you run multiple encodes at the same time, which in this case I can also recommend AV1.

• Preset slow (on x265). If you have a fast machine (I don't), you can go to slower. But from then on, it's not worth the CPU-time (as I found in my tests).

• CRF 24. That's my sweet spot for final movie size. Higher CRF's create smaller files (and I found they encoded faster), and lower CRF's create bigger files (and slower encodes). No big deal here, this was expected.

• 12bit colorspace. Here's the good part. In some of my test encodes (for example in Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m), 10bit encode provided 2% smaller and VMAF better results. But, in most other commercial clips I did some testing, I found that 12bit encoding gives better results (smaller size AND better VMAF). It goes without talking that they both are better than 8bit encoding of those 8bit source videos. If you go to 10bit source videos, 12bit encoding also gives better results than 10bit encoding. I'm no master at why this happens, the other answers provide some insight to that, but I also did some screenshots comparison of comparable size 8bit/10bit/12bit encodes of 8bit/10bit content, and I consistently liked the 12bit encodes more. They provided smoother gradients where 8bit encoding showed banding. Now the drawback is that going for 10bit/12bit encodes, you may lose hardware-decoding capabilities for the device used for playback (my PC loses hardware playback capability at 12bit), but for my target usage (lowest acceptable quality for small size), the above combination (x265,12bit,slow preset,CRF24) is my sweet spot.

That was my experience, backed by extensive testing, feel free to run some tests yourself.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.