0

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.

  • Please split this up in to three questions. – AJ Henderson Nov 14 '17 at 14:35
1

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

| improve this answer | |
  • 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 Nov 14 '17 at 19:39
  • Multiple of 8. Memory I/O and data operations are more efficient when working with byte-sized data. – Gyan Nov 15 '17 at 4:48
  • 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 Nov 15 '17 at 5:49
  • 1
    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 Nov 15 '17 at 6:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.