<p>From <a href="http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf" rel="nofollow noreferrer">Why does 10-bit save bandwidth (even when content is 8-bit)?</a></p>

<blockquote>
  <p>When encoding with the 10-bit tool, the compression process is
  performed with at least 10-bit accuracy compared to only 8-bit
  otherwise. So there is less truncation errors, especially in the
  motion compensation  stage, increasing the efficiency of compression 
  tools. As a consequence, there is less need to quantize to achieve a
  given bit-rate.</p>
  
  <p>The net result is a better quality for the same bit-rate or conversely
  less bit-rate for the same quality: between 5% and 20% on typical
  sources.</p>
</blockquote>

<p>See the link for additional info.</p>

CC BY-SA 4.0
2019-01-08T18:46:41.177Z
2019-01-08T18:46:41.177Z
llogan
<p>Our workflow involves huge 8K clips(i.e., 8192x8192). The inputs are mostly very high bitrates 264/265 clips, though we are using ProRes or  DNxHD for post-production within the process, we do not want to archive such huge files as the "master" copies(easily over 100GB for 1 minute).</p>

<p>My current approach is, using FFMPEG to compress the ProRes/DHxHD clips into H.265 clips using a very high-quality setting (crf=12, slow profile).</p>

<p>Another quality related setting is the pixel format config. Then my question comes up:</p>

<p>Targeting the same clips(5 of them), using the same compress settings, one with yuv420 8-bit, one with yuv444 10-bit, yuv444 outputs are constantly smaller than yuv420 outputs(5%-10%), i.e, lower bitrates.</p>

<p>If yuv444 10-bit needs to store more information, how could this be possible?</p>

CC BY-SA 4.0
2019-01-08T23:00:00.847Z
I can't answer your question, but may I ask which camers you are using? As not even RED's r3d codec at 8k uses so much storage. Thanks.
Timothy Lukas H.
CC BY-SA 4.0
2019-01-09T02:39:10.957Z
Yes, this is not from a single camera, they are VR content, a multiple camera setup.
Jerry Tian
<ffmpeg><h.265>
H.265(libx265) codec for 8K videos, using same compress settings, why yuv444 10-bit is saving bitrates than yuv420 8-bit?
Jerry Tian
# H.265(libx265) codec for 8K videos, using same compress settings, why yuv444 10-bit is saving bitrates than yuv420 8-bit?

(Asked by: username_0 on 2019-01-08)

Our workflow involves huge 8K clips(i.e., 8192x8192). The inputs are mostly very high bitrates 264/265 clips, though we are using ProRes or DNxHD for post-production within the process, we do not want to archive such huge files as the "master" copies(easily over 100GB for 1 minute).

My current approach is, using FFMPEG to compress the ProRes/DHxHD clips into H.265 clips using a very high-quality setting (crf=12, slow profile).

Another quality related setting is the pixel format config. Then my question comes up:

Targeting the same clips(5 of them), using the same compress settings, one with yuv420 8-bit, one with yuv444 10-bit, yuv444 outputs are constantly smaller than yuv420 outputs(5%-10%), i.e, lower bitrates.

If yuv444 10-bit needs to store more information, how could this be possible?

**Tags:** ffmpeg, h.265

> **Comments:**
> **username_1**: I can't answer your question, but may I ask which camers you are using? As not even RED's r3d codec at 8k uses so much storage. Thanks.  
> **username_0**: Yes, this is not from a single camera, they are VR content, a multiple camera setup.  

---

## 1 answers

### Answer by username_2 on 2019-01-08. Score: 1 | Accepted answer

From [Why does 10-bit save bandwidth (even when content is 8-bit)?](http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf)

> When encoding with the 10-bit tool, the compression process is
> performed with at least 10-bit accuracy compared to only 8-bit
> otherwise. So there is less truncation errors, especially in the
> motion compensation stage, increasing the efficiency of compression
> tools. As a consequence, there is less need to quantize to achieve a
> given bit-rate.
>
> The net result is a better quality for the same bit-rate or conversely
> less bit-rate for the same quality: between 5% and 20% on typical
> sources.

See the link for additional info.


---

