user14388: 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?

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

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

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

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

<p>Also, then is 12bit better than 10bit or are the rounding errors insignificant at that point?</p>
 27287: <p>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:</p>

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

<p>Hope that helps.</p>
 33418: <p>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:</p>
<p>• 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.</p>
<p>• 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).</p>
<p>• 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.</p>
<p>• 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.</p>
<p>That was my experience, backed by extensive testing, feel free to run some tests yourself.</p>
 15933: <p>I can answer your first question. <strong>At the same bitrate and transcoding from an 8-bit source</strong> 10-bit HEVC is better than 8-bit HEVC, because it hardcodes dither. <a href="https://web.archive.org/web/20190610103731/https://gist.github.com/l4n9th4n9/4459997" rel="nofollow noreferrer">archived version of https://gist.github.com/l4n9th4n9/4459997</a>
I am still unsure, whether that makes 12-bit HEVC transcodes superior  to 10-bit, thats why I ended up here.</p>
