Answers.Body: <p><code>crf=18</code> rate-control produces bigger files in 12-bit mode.  If you're trying to find some encode settings that work well for some content, you shouldn't assume that the same CRF at different bit depths is going to be the same.  (Either the same SSIM or the same perceptual visual quality).</p>
  
  <p>You haven't said anything about quality, or quality-per-filesize.  Presumably the bigger files also look a bit better, since 12-bit x265 has about the same quality per bitrate as 8-bit x265.  (I've tested with 10 vs. 8, but not with 12).</p>
  
  <p><strong>CRF is <em>not</em> an exact target-quality setting.  So if you want to compare settings, use 2pass with the same bitrate for both and look at quality.</strong>  Use either SSIM or preferably human visual inspection.  (Some people like to pause/zoom, but don't <em>just</em> do that.  Some kinds of artifacts / distortion are noticeable when the video is playing, but many are a lot less noticeable.  Pause/zoom helps when checking your visual impression of "sharpness" / "more detail", so figure out what was giving you that impression, and maybe also other things to look for to see if you can still notice them while playing the video.)</p>
  
  <p><strong>For actual encodes once you find settings that you like, CRF is great, but it's no good for comparing the quality-per-bitrate of different encode settings.</strong></p>
  
  <hr>
  
  <h3>8-bit vs. 10/12-bit</h3>
  
  <p>There may still be some gains in compression efficiency for x265, but they're definitely smaller if they exist at all.  10 or 12-bit might even look a tiny bit worse.  See discussion on <a href="http://forum.doom9.org/archive/index.php/t-167081.html" rel="nofollow noreferrer">doom9</a>, linked by Michael in a comment.  I haven't followed the latest discussions, so I'm not sure what the current consensus is on 10-bit x265 for 8-bit video.  Even if there is a small gain, it may not be worth the speed penalty.</p>
  
  <p>It's definitely nowhere near a factor of 12/8 like some commenters are suggesting based on "simple math".  A lossy video codec like h.265 isn't very similar to simple lossless compression like ZIP.</p>
  
  <p><strong>x264 <em>does</em> benefit in general from running in 10-bit mode even when the original source is 8-bit, and so is the final display</strong> (but again, you shouldn't expect the same CRF to give the same bitrate or the same quality at different depths).  <strong>8-bit h.265 has higher-precision motion vectors than 8-bit h.264, so that part of the reasoning doesn't apply to x265.</strong></p>
  
  <p>Remember that both h.264 and h.265 store the information in the video as quantized frequency-domain coefficients.  With trellis / rdoq, it even tweaks the quantization to compress well with the final entropy-coder (e.g. CABAC in h.264), so the same number of bits can represent the same amount of information, whether the entropy-coder had 8-bit or 12-bit input.  8-bit is in some ways just a speed-hack.</p>
  
  <p>More bits means that you can get closer (smaller error) while still having some error.  So the encoder has more choice when trading off distortion vs. bitrate.  This may be partly why 10-bit x264 suffers less from "banding" artifacts in gradients: it has more choice in representing the DC coefficient, or in having small values in the AC coefficients.</p>
  
  <hr>
  
  <p>The higher the input bit-depth (for a given output bitrate), the more bits the encoder has to throw away.  A lot of those extra bits are zeros if your original video was 8-bit.  (Lossy encoding already throws away a <em>lot</em> of bits, like from 12 bpp per frame (for YUV 4:2:0 chroma-sub-sampling with 8-bit components) down to 0.15 bits/pixel/frame and still look pretty close to visually transparent, especially at high resolutions where typical video has its information content distributed over more pixels.)</p>
  
  <p>If you're going to rescale, presumably going to 10 or 12-bit before rescaling will let the rescale blend pixels with less loss of information.  (e.g. a 10-bit value can exactly store the average of four 8-bit values.)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-05T01:39:37.170Z
Answers.LastActivityDate: 2017-06-05T01:48:12.307Z
Answers.LastEditDate: 2017-06-05T01:48:12.307Z
Answers.UserDisplayName: Peter Cordes
Body: <p>Just got curious of this x265 HEVC format, and tried it on a 1920x1080i BDMV stream video, one encoded with 8bit depth and then another encoded with 12bit depth. The results are, the 8bit output was smaller. Both outputs are 1280x720.</p>
  
  <p>I wonder why is this so.</p>
  
  <p>Here are the MediaInfo:</p>
  
  <p><strong>8bit:</strong></p>
  
  <p>Frame rate                     : 23.976 fps</p>
  
  <p>Color space                    : YUV</p>
  
  <p>Chroma subsampling             : 4:2:0</p>
  
  <p>Bit depth                      : 8 bits</p>
  
  <p>Writing library                : x265 1.9+54-291beccb6760:[Windows][GCC 5.3.0][64 bit] 8bit+10bit+12bit</p>
  
  <p>Encoding settings              : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=2 / tu-inter-depth=2 / me=3 / subme=3 / merange=57 / rect / amp / max-merge=3 / temporal-mvp / no-early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=23 / scenecut=40 / rc-lookahead=30 / lookahead-slices=4 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=4 / limit-refs=2 / limit-modes / weightp / weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=6 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=1.00 / no-rd-refine / signhide / deblock / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30</p>
  
  <p><strong>12bit:</strong>
  Frame rate                     : 23.976 fps</p>
  
  <p>Color space                    : YUV</p>
  
  <p>Chroma subsampling             : 4:2:0</p>
  
  <p>Bit depth                      : 12 bits</p>
  
  <p>Writing library                : x265 1.9+194-6d3849d648f0be5a:[Windows][GCC 5.3.0][64 bit] 12bit: KG7x [x265.ru]</p>
  
  <p>Encoding settings              : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=2 / tu-inter-depth=2 / me=3 / subme=3 / merange=57 / rect / amp / max-merge=3 / temporal-mvp / no-early-skip / recursion-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=23 / scenecut=40 / rc-lookahead=30 / lookahead-slices=4 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=4 / limit-refs=2 / limit-modes / weightp / weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=6 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=1.00 / no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-06-03T05:24:05.067Z
Comments.Text: Why would you expect the 12-bit to be smaller? Higher bit-depth = more bits to store. Now, for certain materials like animation with flat colors or smooth gradients, you can compress it better, but does not apply in general.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-06-03T09:10:28.417Z
Comments.Text: I also fail to see the reasoning here, 8bit has less information than 12bit thus making 12bit bigger, even simple maths can answer this without having to go through the whole encoding / compression process
Comments.UserDisplayName: Adam Mann Pro
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-06-03T10:28:36.773Z
Comments.Text: So is it safe to assume that compression would've worked better on higher CRF, and it depends on sample videos since some might have grain, some might have more high motion than others therefore I couldn't utilize the compression algorithms efficiently and instead just compromised the data size for no apparent compression gains?
Comments.UserDisplayName: 58YtQ2H83m17838963l61BU07Y8622
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-06-10T01:01:55.133Z
Comments.Text: Yes, you are not gaining anything from expanding an 8-bit source to 12-bit. I would suggest using this source to play around with the encoder: https://mango.blender.org/
Comments.UserDisplayName: Michael Steinberg
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-10-06T20:13:22.557Z
Comments.Text: Just wanted to clarify that this is true for 265 only. 264 video will benefit from bit expansion. See discussion [here](http://forum.doom9.org/archive/index.php/t-167081.html)
Comments.UserDisplayName: Michael Steinberg
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-05T01:49:36.540Z
Comments.Text: @AdamMannPro: that kind of simple math doesn't work for lossy codecs that quantize anyway before feeding data to an entropy coder.  See my answer.  The answer to the file-size question has everything to do with x265's CRF ratecontrol behaviour, and very little to do with whether 12-bit x265 is better, equal, or worse quality per bitrate when converted back to 8-bit.
Comments.UserDisplayName: Peter Cordes
Tags: <video><encoding>
Title: x265 encoding test: 12bit results a bigger file size than 8bit of the same config?
UserDisplayName: 58YtQ2H83m17838963l61BU07Y8622
ThreadText: # x265 encoding test: 12bit results a bigger file size than 8bit of the same config?
  
  (Asked by: username_0 on 2016-06-03)
  
  Just got curious of this x265 HEVC format, and tried it on a 1920x1080i BDMV stream video, one encoded with 8bit depth and then another encoded with 12bit depth. The results are, the 8bit output was smaller. Both outputs are 1280x720.
  
  I wonder why is this so.
  
  Here are the MediaInfo:
  
  **8bit:**
  
  Frame rate : 23.976 fps
  
  Color space : YUV
  
  Chroma subsampling : 4:2:0
  
  Bit depth : 8 bits
  
  Writing library : x265 1.9+54-291beccb6760:[Windows][GCC 5.3.0][64 bit] 8bit+10bit+12bit
  
  Encoding settings : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=2 / tu-inter-depth=2 / me=3 / subme=3 / merange=57 / rect / amp / max-merge=3 / temporal-mvp / no-early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=23 / scenecut=40 / rc-lookahead=30 / lookahead-slices=4 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=4 / limit-refs=2 / limit-modes / weightp / weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=6 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=1.00 / no-rd-refine / signhide / deblock / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30
  
  **12bit:**
  Frame rate : 23.976 fps
  
  Color space : YUV
  
  Chroma subsampling : 4:2:0
  
  Bit depth : 12 bits
  
  Writing library : x265 1.9+194-6d3849d648f0be5a:[Windows][GCC 5.3.0][64 bit] 12bit: KG7x [x265.ru]
  
  Encoding settings : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=2 / tu-inter-depth=2 / me=3 / subme=3 / merange=57 / rect / amp / max-merge=3 / temporal-mvp / no-early-skip / recursion-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=23 / scenecut=40 / rc-lookahead=30 / lookahead-slices=4 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=4 / limit-refs=2 / limit-modes / weightp / weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=6 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=1.00 / no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30
  
  **Tags:** video, encoding
  
  > **Comments:**
  > **username_1**: Why would you expect the 12-bit to be smaller? Higher bit-depth = more bits to store. Now, for certain materials like animation with flat colors or smooth gradients, you can compress it better, but does not apply in general.  
  > **username_2**: I also fail to see the reasoning here, 8bit has less information than 12bit thus making 12bit bigger, even simple maths can answer this without having to go through the whole encoding / compression process  
  > **username_0**: So is it safe to assume that compression would've worked better on higher CRF, and it depends on sample videos since some might have grain, some might have more high motion than others therefore I couldn't utilize the compression algorithms efficiently and instead just compromised the data size for no apparent compression gains?  
  > **username_3**: Yes, you are not gaining anything from expanding an 8-bit source to 12-bit. I would suggest using this source to play around with the encoder: https://mango.blender.org/  
  > **username_3**: Just wanted to clarify that this is true for 265 only. 264 video will benefit from bit expansion. See discussion [here](http://forum.doom9.org/archive/index.php/t-167081.html)  
  > **username_4**: @username_2: that kind of simple math doesn't work for lossy codecs that quantize anyway before feeding data to an entropy coder.  See my answer.  The answer to the file-size question has everything to do with x265's CRF ratecontrol behaviour, and very little to do with whether 12-bit x265 is better, equal, or worse quality per bitrate when converted back to 8-bit.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_4 on 2017-06-05. Score: 2
  
  `crf=18` rate-control produces bigger files in 12-bit mode. If you're trying to find some encode settings that work well for some content, you shouldn't assume that the same CRF at different bit depths is going to be the same. (Either the same SSIM or the same perceptual visual quality).
  
  You haven't said anything about quality, or quality-per-filesize. Presumably the bigger files also look a bit better, since 12-bit x265 has about the same quality per bitrate as 8-bit x265. (I've tested with 10 vs. 8, but not with 12).
  
  **CRF is *not* an exact target-quality setting. So if you want to compare settings, use 2pass with the same bitrate for both and look at quality.** Use either SSIM or preferably human visual inspection. (Some people like to pause/zoom, but don't *just* do that. Some kinds of artifacts / distortion are noticeable when the video is playing, but many are a lot less noticeable. Pause/zoom helps when checking your visual impression of "sharpness" / "more detail", so figure out what was giving you that impression, and maybe also other things to look for to see if you can still notice them while playing the video.)
  
  **For actual encodes once you find settings that you like, CRF is great, but it's no good for comparing the quality-per-bitrate of different encode settings.**
  
  ---
  
  ### 8-bit vs. 10/12-bit
  
  There may still be some gains in compression efficiency for x265, but they're definitely smaller if they exist at all. 10 or 12-bit might even look a tiny bit worse. See discussion on [doom9](http://forum.doom9.org/archive/index.php/t-167081.html), linked by username_3 in a comment. I haven't followed the latest discussions, so I'm not sure what the current consensus is on 10-bit x265 for 8-bit video. Even if there is a small gain, it may not be worth the speed penalty.
  
  It's definitely nowhere near a factor of 12/8 like some commenters are suggesting based on "simple math". A lossy video codec like h.265 isn't very similar to simple lossless compression like ZIP.
  
  **x264 *does* benefit in general from running in 10-bit mode even when the original source is 8-bit, and so is the final display** (but again, you shouldn't expect the same CRF to give the same bitrate or the same quality at different depths). **8-bit h.265 has higher-precision motion vectors than 8-bit h.264, so that part of the reasoning doesn't apply to x265.**
  
  Remember that both h.264 and h.265 store the information in the video as quantized frequency-domain coefficients. With trellis / rdoq, it even tweaks the quantization to compress well with the final entropy-coder (e.g. CABAC in h.264), so the same number of bits can represent the same amount of information, whether the entropy-coder had 8-bit or 12-bit input. 8-bit is in some ways just a speed-hack.
  
  More bits means that you can get closer (smaller error) while still having some error. So the encoder has more choice when trading off distortion vs. bitrate. This may be partly why 10-bit x264 suffers less from "banding" artifacts in gradients: it has more choice in representing the DC coefficient, or in having small values in the AC coefficients.
  
  ---
  
  The higher the input bit-depth (for a given output bitrate), the more bits the encoder has to throw away. A lot of those extra bits are zeros if your original video was 8-bit. (Lossy encoding already throws away a *lot* of bits, like from 12 bpp per frame (for YUV 4:2:0 chroma-sub-sampling with 8-bit components) down to 0.15 bits/pixel/frame and still look pretty close to visually transparent, especially at high resolutions where typical video has its information content distributed over more pixels.)
  
  If you're going to rescale, presumably going to 10 or 12-bit before rescaling will let the rescale blend pixels with less loss of information. (e.g. a 10-bit value can exactly store the average of four 8-bit values.)
  
  
  ---
  
  