3

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

Improve this question
6
  • 2
    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.
    – Gyan
    Commented Jun 3, 2016 at 5:24
  • 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
    – Adam Mann Pro
    Commented Jun 3, 2016 at 9:10
  • 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?
    – 58YtQ2H83m17838963l61BU07Y8622
    Commented Jun 3, 2016 at 10:28
  • 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: mango.blender.org
    – Michael Steinberg
    Commented Jun 10, 2016 at 1:01
  • 1
    @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.
    – Peter Cordes
    Commented Jun 5, 2017 at 1:49

1 Answer 1

Reset to default
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, 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.

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.)

Improve this answer

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.