Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-20T19:57:01.073Z
Answers.Text: 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.
Answers.UserDisplayName: Fallen
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-10-29T04:44:16.190Z
Answers.Text: 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.
Answers.UserDisplayName: pyrocrasty
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-01-09T04:20:54.677Z
Answers.Text: 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.
Answers.UserDisplayName: Hashim Aziz
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2016-06-20T08:27:05.157Z
Answers.LastActivityDate: 2021-11-10T10:26:27.990Z
Answers.LastEditDate: 2021-11-10T10:26:27.990Z
Answers.UserDisplayName: Lakis01
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-01-06T11:37:48.477Z
Answers.LastActivityDate: 2020-01-07T01:47:47.833Z
Answers.LastEditDate: 2020-01-07T01:47:47.833Z
Answers.UserDisplayName: NicolasPP
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-01-03T15:33:21.060Z
Answers.LastActivityDate: 2021-01-03T15:33:21.060Z
Answers.UserDisplayName: Th Econ
Body: <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>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-04-19T11:18:46.017Z
Comments.Text: 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.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-04-27T14:02:01.107Z
Comments.Text: 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.
Comments.UserDisplayName: stib
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-04-28T01:39:25.723Z
Comments.Text: @stib, Everything I have read suggests the opposite. http://myanimelist.net/forum/?topicid=358699#msg12115983 https://gist.github.com/l4n9th4n9/4459997#L37
Comments.UserDisplayName: Fallen
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-04-28T04:46:05.730Z
Comments.Text: 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.
Comments.UserDisplayName: stib
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-04-28T19:49:39.280Z
Comments.Text: Are you sure your not using 12 bit raw vs like 12 bit hevc/x264? Because raw anything is **huge**.
Comments.UserDisplayName: Fallen
Tags: <video><video-quality><encoding>
Title: 8bit vs 10bit vs 12bit
UserDisplayName: Fallen
ThreadText: # 8bit vs 10bit vs 12bit
  
  (Asked by: username_0 on 2016-04-19)
  
  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?
  
  **Tags:** video, video-quality, encoding
  
  > **Comments:**
  > **username_1**: 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.  
  > **username_2**: 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.  
  > **username_0**: @username_2, Everything I have read suggests the opposite. http://myanimelist.net/forum/?topicid=358699#msg12115983 https://gist.github.com/l4n9th4n9/4459997#L37  
  > **username_2**: 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.  
  > **username_0**: Are you sure your not using 12 bit raw vs like 12 bit hevc/x264? Because raw anything is **huge**.  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_3 on 2016-06-20. Score: 9
  
  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](https://web.archive.org/web/20190610103731/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.
  
  > **Comments:**
  > **username_0**: 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.  
  > **username_5**: 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.  
  > **username_4**: 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.  
  
  ---
  
  ### Answer by username_6 on 2020-01-06. Score: 7
  
  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.
  
  
  ---
  
  ### Answer by username_7 on 2021-01-03. Score: 6
  
  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 username_1.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.
  
  
  ---
  
  