<p>2nd question: RGB JPEG can use all kinds of subsamplings, including 4:2:0 with &quot;center&quot; G, B siting. It makes little sense, since we have better vision in green.</p>

CC BY-SA 4.0
2021-08-16T22:45:45.463Z
2021-08-16T22:45:45.463Z
Валерий Заподовников
<p><em>Are YUV and YCbCr the same thing?</em> → strictly, no. The former is applied to analog signals, and the latter to digital. But media apps (like Mediainfo) use YUV as the designated term.</p>

<p><em>It doesn't make any sense to say RGB 4:2:0, right?</em> → Not theoretically incoherent, but I haven't seen any codec that implements subsampling for RGB pixels except for Bayer RGB streams possibly. Don't know its details. </p>

<p><em>What is the "raw sample" here?</em> → a stored single value of a pixel component i.e. any of R,G,B,Y,U,V (or alpha).</p>

<p><em>Is the 8 bits value referred to the number of bits used for each component (Y, Cb, Cr) before doing chroma subsampling?</em> → it is the resolved bits per individual sample i.e. a 12-bit value has to be stored as a 16-bit datum, so 12 bits is the raw sample size and 16 bits is the coded sample size. 4 bits are for padding.</p>

<p><em>how should I calculate how many bits per pixel</em> → in terms of luma/chroma resolution, it's the raw sample size. In terms of storage space for a raw uncompressed stream, you sum up the counts in the sampling scheme and divide by maximum count. Multiply by (no. of components x coded sample size).</p>

<p>So, for 4:2:2, that's</p>

<p><code>(4+2+2) / (4+4+4) = 2/3</code> and then <code>2/3 x (3 x 8 bits) = 16 bits per sample</code></p>

CC BY-SA 3.0
2017-11-14T19:39:36.997Z
Thank you. Just one thing: when you say that `a 12-bit value has to be stored as a 16-bit datum`, where does the 16 bits value come from?
mcont
CC BY-SA 3.0
2017-11-15T04:48:37.873Z
Multiple of 8. Memory I/O and data operations are more efficient when working with byte-sized data.
Gyan
CC BY-SA 3.0
2017-11-15T05:49:11.937Z
So when we talk about 10-bit video, the actual sample is stored with 16 bits. Do you have any external resource about this you can point me to? Thanks
mcont
CC BY-SA 3.0
2017-11-15T06:24:00.920Z
This is applicable for a raw uncompressed video stream. Strictly only true for raw streams in planar format. Packed formats (R, G and B values for each pixel are stored one after another) will also be padded if the total size of each pixel does not end on a memory access boundary. Doesn't apply to encoded data as those coded words don't map 1-to-1 to raw samples. Authoritative source is to look at source code of apps which encode and decode raw streams e.g. ffmpeg. Look in `libavcodec/rawdec.c`
Gyan
CC BY-SA 3.0
2017-11-14T05:27:13.647Z
2017-11-14T05:37:17.103Z
2017-11-14T05:37:17.103Z
Gyan
<p>Hy everyone, I have some questions about color spaces and chroma subsampling that I haven't been able to solve just by searching the web.</p>

<ol>
<li><p>Are <code>YUV</code> and <code>YCbCr</code> the same thing? When I take a look at the information of a random MP4 video file with <code>ffmpeg</code> or <code>MediaInfo</code>, I see that the color space is indicated as <code>YUV</code>. Is that actually <code>YCbCr</code> since we're talking about a digital file?</p></li>
<li><p>It doesn't make any sense to say <code>RGB 4:2:0</code>, right? Because chroma subsampling only applies to the <code>YCbCr</code> color space, taking the (Cb, Cr) components, and deciding how many of them should be but in a 4x2 pixels region. Is that correct?</p></li>
<li><p>When <code>ffprobe</code> outputs that a video has a <code>bits_per_raw_sample</code> (or bit depth) of 8 bits with a <code>yuv420p</code> pixel format, what does it mean? What is the "raw sample" here? Is the 8 bits value referred to the number of bits used for each component (Y, Cb, Cr) before doing chroma subsampling? In that case, how should I calculate how many bits per pixel (or per 4x2 pixels region [?]) are used after chroma subsampling?</p></li>
</ol>

<p>I hope it's ok to have multiple questions in the same post. Thank you.</p>

CC BY-SA 3.0
2017-11-14T14:35:24.100Z
Please split this up in to three questions.
AJ Henderson
<colorspace>
Doubts about color spaces and chroma subsampling
mcont
# Doubts about color spaces and chroma subsampling

(Asked by: username_0 on 2017-11-13)

Hy everyone, I have some questions about color spaces and chroma subsampling that I haven't been able to solve just by searching the web.

1. Are `YUV` and `YCbCr` the same thing? When I take a look at the information of a random MP4 video file with `ffmpeg` or `MediaInfo`, I see that the color space is indicated as `YUV`. Is that actually `YCbCr` since we're talking about a digital file?
2. It doesn't make any sense to say `RGB 4:2:0`, right? Because chroma subsampling only applies to the `YCbCr` color space, taking the (Cb, Cr) components, and deciding how many of them should be but in a 4x2 pixels region. Is that correct?
3. When `ffprobe` outputs that a video has a `bits_per_raw_sample` (or bit depth) of 8 bits with a `yuv420p` pixel format, what does it mean? What is the "raw sample" here? Is the 8 bits value referred to the number of bits used for each component (Y, Cb, Cr) before doing chroma subsampling? In that case, how should I calculate how many bits per pixel (or per 4x2 pixels region [?]) are used after chroma subsampling?

I hope it's ok to have multiple questions in the same post. Thank you.

**Tags:** colorspace

> **Comments:**
> **username_1**: Please split this up in to three questions.  

---

## 2 answers

### Answer by username_3 on 2017-11-14. Score: 1 | Accepted answer

*Are YUV and YCbCr the same thing?* → strictly, no. The former is applied to analog signals, and the latter to digital. But media apps (like Mediainfo) use YUV as the designated term.

*It doesn't make any sense to say RGB 4:2:0, right?* → Not theoretically incoherent, but I haven't seen any codec that implements subsampling for RGB pixels except for Bayer RGB streams possibly. Don't know its details.

*What is the "raw sample" here?* → a stored single value of a pixel component i.e. any of R,G,B,Y,U,V (or alpha).

*Is the 8 bits value referred to the number of bits used for each component (Y, Cb, Cr) before doing chroma subsampling?* → it is the resolved bits per individual sample i.e. a 12-bit value has to be stored as a 16-bit datum, so 12 bits is the raw sample size and 16 bits is the coded sample size. 4 bits are for padding.

*how should I calculate how many bits per pixel* → in terms of luma/chroma resolution, it's the raw sample size. In terms of storage space for a raw uncompressed stream, you sum up the counts in the sampling scheme and divide by maximum count. Multiply by (no. of components x coded sample size).

So, for 4:2:2, that's

`(4+2+2) / (4+4+4) = 2/3` and then `2/3 x (3 x 8 bits) = 16 bits per sample`

> **Comments:**
> **username_0**: Thank you. Just one thing: when you say that `a 12-bit value has to be stored as a 16-bit datum`, where does the 16 bits value come from?  
> **username_3**: Multiple of 8. Memory I/O and data operations are more efficient when working with byte-sized data.  
> **username_0**: So when we talk about 10-bit video, the actual sample is stored with 16 bits. Do you have any external resource about this you can point me to? Thanks  
> **username_3**: This is applicable for a raw uncompressed video stream. Strictly only true for raw streams in planar format. Packed formats (R, G and B values for each pixel are stored one after another) will also be padded if the total size of each pixel does not end on a memory access boundary. Doesn't apply to encoded data as those coded words don't map 1-to-1 to raw samples. Authoritative source is to look at source code of apps which encode and decode raw streams e.g. ffmpeg. Look in `libavcodec/rawdec.c`  

---

### Answer by username_2 on 2021-08-16. Score: 0

2nd question: RGB JPEG can use all kinds of subsamplings, including 4:2:0 with "center" G, B siting. It makes little sense, since we have better vision in green.


---

