YCbCr Video

YCbCr represents video using luma and two color-difference components that can be coded and sampled separately.

A decoded movie frame often consists of a large plane called Y and two smaller planes called Cb and Cr. Y describes luma. Cb and Cr describe color differences. Together, they provide the information needed to reconstruct the picture's RGB components.

Separating these quantities allows a format to keep fine luma structure while storing color differences at a lower spatial density. That is the basis for chroma subsampling. The component representation and the sampling reduction are separate choices: YCbCr can also carry all three components at full resolution.

Luma is a mixture of encoded components

The prime mark in Y′ or R′G′B′ means that the values have already undergone the relevant nonlinear encoding. In a BT.709 example, normalized encoded RGB components produce:

Y′ = 0.2126 R′ + 0.7152 G′ + 0.0722 B′

The green coordinate has the greatest weight, while blue has the smallest. These weights define this particular matrix. Applying a different standard's weights constructs a different luma coordinate from the same RGB triplet.

Y′ is often described casually as brightness. More precisely, it is luma calculated from encoded components. Physical luminance is a light quantity; it is not obtained by treating every Y′ code as a direct measurement in nits. The transfer interpretation remains part of the relationship to light.

If all three encoded RGB components are equal, their weighted sum equals that common value, because the coefficients sum to one. This is why a neutral gray has a useful simple representation in YCbCr.

The two differences that complete the description

For the same BT.709 representation:

Cb = (B′ − Y′) / 1.8556

Cr = (R′ − Y′) / 1.5748

These equations take the blue-minus-luma and red-minus-luma differences and scale them. In the normalized representation used here, both differences lie in the nominal interval −0.5 to +0.5 for in-range RGB inputs.

Cb is not the blue channel itself. A positive Cb says that B′ exceeds the mixture represented by Y′. Similarly, Cr expresses R′ relative to that mixture. For neutral gray, both differences are zero, even when the gray is bright.

There is no separately stored green-minus-luma plane in this representation. Once Y′, R′, and B′ are known, the luma equation supplies the missing green coordinate. Three independent numbers still describe the position; the coordinate system has changed.

An orange sample, calculated in both directions

Start with an original normalized encoded RGB triplet:

R′ = 0.8, G′ = 0.3, B′ = 0.1.

Its luma is:

Y′ = 0.17008 + 0.21456 + 0.00722 = 0.39186.

The color differences become:

Cb = (0.1 − 0.39186) / 1.8556 ≈ −0.157286.

Cr = (0.8 − 0.39186) / 1.5748 ≈ +0.259169.

Notice that neither difference resembles an unsigned blue or red intensity. They are signed differences around the neutral point.

To recover RGB before quantization, rearrange the same equations:

R′ = Y′ + 1.5748 Cr = 0.8

B′ = Y′ + 1.8556 Cb = 0.1

G′ = (Y′ − 0.2126 R′ − 0.0722 B′) / 0.7152 = 0.3

The forward and inverse calculations return the original triplet. The matrix itself is a change of coordinates. Precision reduction, subsampling, or subsequent lossy coding can introduce losses, which should be distinguished from this unrounded conversion.

Turning signed differences into unsigned codes

A common 8-bit limited-range coding scales luma by 219 and offsets it by 16. Chroma uses scale 224 and neutral offset 128. Round the resulting values to the nearest integer:

Component	Unrounded code calculation	Stored code
Y	16 + 219 × 0.39186 = 101.81734	102
Cb	128 + 224 × (−0.157286) ≈ 92.7679	93
Cr	128 + 224 × 0.259169 ≈ 186.0539	186

The negative Cb is now stored as a positive byte below neutral 128. A reader recovers the signed coordinate by removing that offset, then dividing by the chroma scale.

For these rounded bytes:

Y′ = (102 − 16) / 219 ≈ 0.392694

Cb = (93 − 128) / 224 = −0.15625

Cr = (186 − 128) / 224 ≈ 0.258929

Using the inverse matrix gives approximately (0.80045, 0.30075, 0.10276). The small difference from the original comes from rounding the three coded coordinates. Increasing coding precision makes those coordinate steps finer.

This is a single-position example with full chroma information. With 4:2:0, a reconstruction stage also estimates the chroma needed at that position from the smaller, correctly located chroma grids.

Where this enters playback

A source file's color signaling tells the playback stack which interpretation is intended. An Emby client rendering original video uses that source interpretation; a conversion must interpret the input correctly before producing and describing the output.

For a color error that appears only after conversion, comparing the source and output matrix and range fields is therefore useful. Changing a label is appropriate when the samples were merely mislabeled. If the samples have actually been transformed using the wrong matrix, producing correct colors requires correcting the sample calculation as well.

Why the matrix name matters

BT.601, BT.709, and BT.2020 do not all use the same matrix. Suppose our unrounded BT.709 Y′, Cb, and Cr are instead reconstructed using the BT.601 inverse coefficients. The result is approximately (0.7552, 0.2609, 0.1132), rather than (0.8, 0.3, 0.1).

Every sample can have reached the decoder intact; the visible color still moves because the inverse calculation disagrees with the forward one. Neutral grays are a poor test for this particular mistake: their chroma differences are zero, so several matrices reconstruct them similarly. Colored objects expose the disagreement more clearly.

The term YUV frequently appears in APIs and pixel-format names for this family of video representations. In digital file and frame descriptions, the actual components are commonly Y′CbCr. The API's documented equations, range, and component order establish the intended representation.

BT.2020 also distinguishes constant-luminance and non-constant-luminance representations. A matrix identifier should be interpreted as its specified representation, rather than shortened to a generic assumption that every YCbCr conversion uses the equations above.