4:2:0 chroma subsampling 2026-11-05
4:2:0 chroma subsampling keeps the full luma grid while halving each colour-difference component's sampling rate horizontally and vertically. For even width and height , it retains Y samples and samples each of Cb and Cr.[ref]
Recommended 8-Bit YUV Formats for Video Rendering by Gary Sullivan and Stephen Estrop. YUV Sampling,4:2:0 definition
The zero in the notation does not mean that one colour-difference component has disappeared.For an original six-by-four eight-bit image, the active payload iscompared with 72 bytes for 4:4:4 chroma sampling and 48 bytes for 4:2:2 chroma subsampling. Thus the 4:2:0 payload is half the 4:4:4 payload and three quarters of the 4:2:2 payload under these declared assumptions. It averages 12 bits per original pixel, without row padding or alpha.
Both colour components have fewer samples, so chroma reconstruction must estimate values at additional positions before a full-resolution colour conversion. It cannot generally reverse information discarded during downsampling. The chroma sample location also matters: identical counts can correspond to different spatial offsets.
4:2:2 chroma subsampling 2026-11-05
4:2:2 chroma subsampling keeps the full luma sample count while sampling each colour-difference component at half the horizontal rate and the full vertical rate. Thus a horizontal group with four Y samples has two Cb and two Cr samples.[ref]
For an original sample-count example, let the grid be six positions wide and three rows high. It contains 18 Y samples and nine samples of each colour-difference component. At eight bits per sample, its active payload isThe corresponding 4:4:4 chroma sampling payload is 54 bytes. The reduction is one third, or from 24 to 16 bits per original pixel. These counts omit padding and any alpha channel; they describe a sampling grid rather than every storage API's alignment constraints.
Horizontal fine colour detail can be lost even though the vertical sample count is unchanged. If a colour-difference row alternates between codes 40 and 160 at every luma position, pair averaging gives three samples of 100 on the stipulated six-position row. Interpolating from those averages cannot identify the original alternation. A low-pass filter and an explicit chroma sample location describe how the reduction is performed; the ratio alone does not specify either.
For a grid whose colour samples share the luma row coordinates, chroma reconstruction needs to estimate missing horizontal positions without inventing a missing vertical row. A later conversion to 4:2:0 chroma subsampling additionally reduces the colour sampling vertically. Rearranging the same 4:2:2 samples between packed pixel formats and planar pixel formats changes layout without making that further sampling reduction.
Chroma interpolation filter 2026-11-05
A chroma interpolation filter combines retained colour-difference samples to estimate values at the output locations required by chroma upsampling. It acts on the components of YCbCr separately from full-resolution luma. The filter coefficients and the assumed chroma sample location jointly determine the reconstruction. Microsoft's primary conversion guide gives a four-sample interpolation example and states its progressive-scan and edge-handling assumptions.[ref]
For an original one-dimensional linear interpolation rule, let retained samples lie at positions . Define output samples byThe two coefficient sets, one for each output parity, both sum to one. A constant input is therefore reproduced at every output position. With , and , the outputs through are . The values at odd-integer positions are estimates, while the retained even-integer positions are unchanged.
Higher-order interpolation need not remain between neighbouring input values. As an original exact-arithmetic illustration, take a half-position rule with coefficients applied to four consecutive samples. Their sum is one, so constants are preserved. But the sample sequence yields between the two central samples; yields . Negative coefficients permit overshoot. Quantization and clipping then change the result further. The primary Microsoft example uses these interpolation coefficients with integer rounding and clipping.[ref]
Recommended 8-Bit YUV Formats for Video Rendering by Gary Sullivan and Stephen Estrop. four-sample Cout formula and subsequent interpolation discussion
The same numerical coefficients can produce spatially misplaced colour if their assumed input grid is wrong. Centered chroma and co-sited chroma require their actual coordinates to be respected. At image boundaries, missing neighbours require an explicit extension rule. No choice of chroma interpolation filter can uniquely recover arbitrary colour variation discarded by chroma subsampling.
Chroma reconstruction 2026-11-05
Chroma reconstruction estimates colour-difference values on a desired spatial grid from the samples retained by chroma subsampling. In YCbCr video, chroma upsampling can bring the reduced Cb and Cr arrays onto the luma grid before a full-resolution conversion to RGB. The sampling ratio, chroma sample location and chosen interpolation rule all affect the result.[ref]
For an original one-dimensional example, let a component have codes at and at . Linear interpolation givesAt , this gives 60, while nearest-neighbor interpolation selects 40. Both methods use the same retained samples; they make different assumptions about the values between them.
No reconstruction rule can infer every discarded variation from these two numbers alone. The functionsagree at zero and two, yet at they give 80 and 90. Thus the retained endpoints do not uniquely identify the interior signal. Recovery guarantees require additional restrictions on the signal and sampling process.
A practical reconstruction also specifies how to handle image edges, where a filter may ask for samples beyond the available array. The Microsoft example states its progressive-scan assumption and supplies separate edge equations; those details are part of the method rather than consequences of the ratio 4:2:0.[ref]
Recommended 8-Bit YUV Formats for Video Rendering by Gary Sullivan and Stephen Estrop. Converting 4:2:0 YUV to4:2:2 YUV, assumptions and edge handling
Increasing the number of output samples therefore does not, by itself, restore the original colour detail. Chroma subsampling 2026-11-05
Chroma subsampling represents colour-difference components on a coarser spatial grid than luma. In YCbCr video, 4:4:4 chroma sampling keeps full sample counts for every component; 4:2:2 chroma subsampling halves the colour-difference count horizontally; 4:2:0 chroma subsampling halves it horizontally and vertically.[ref]
Recommended 8-Bit YUV Formats for Video Rendering by Gary Sullivan and Stephen Estrop. YUV Sampling, definitions of4:4:4,4:2:2 and4:2:0
For an original eight-bit image with no padding or alpha, full sampling uses eight samples in each of three components: 24 bytes. With horizontal halving, the count becomes bytes. Halving in both directions gives bytes. These count active samples, not the allocation overhead of a particular pixel format.
The reduction loses information unless the discarded variations are otherwise constrained. For a stipulated pair of neighbouring samples with constant luma, let one colour-difference channel have values and . Averaging the pair and retaining only the average stores zero. Reconstructing both positions as zero cannot recover which one was originally positive. Fine colour variation can therefore disappear even though both luma samples remain intact.
A low-pass filter before reducing the sampling rate controls aliasing; merely dropping alternate samples need not. Later chroma reconstruction estimates the missing positions. It must respect chroma sample location: equal sample counts do not determine where those samples lie relative to the luma grid. The Microsoft primary guide explicitly distinguishes different 4:2:0 grids and discusses interpolation during format conversion.[ref]
Recommended 8-Bit YUV Formats for Video Rendering by Gary Sullivan and Stephen Estrop. YUV Sampling diagrams; Converting4:2:0 YUV to4:2:2 YUV
Storage organization is independent of this sampling ratio. NV12 interleaves the two reduced components in a second plane, while a fully planar pixel format can store them in separate planes. Rearranging the same samples changes layout, not sampling resolution.
Chroma upsampling 2026-11-05
Chroma upsampling increases the spatial sample count of the colour-difference components after chroma subsampling. For example, converting 4:2:0 chroma subsampling to 4:2:2 chroma subsampling doubles the vertical colour sample count, while conversion to 4:4:4 chroma sampling also doubles it horizontally.[ref]
Recommended 8-Bit YUV Formats for Video Rendering by Gary Sullivan and Stephen Estrop. Converting4:2:0 YUV to4:2:2 YUV and Converting4:2:2 YUV to4:4:4 YUV
The added values are estimates, not newly measured image detail.An original one-dimensional derivation separates increasing the grid density from interpolation. Start with samples and insert zero-valued placeholders:Apply the chroma interpolation filterIt follows that and . Thus this stipulated filter preserves the original positions and fills the intervening positions by linear interpolation.
The scaling is essential. For a constant input , the correctly scaled result is128 at every output position. Using the ordinary three-tap averaging coefficients on the zero-inserted sequence would instead give64 everywhere. Those coefficients are suitable for a different operation; their unit sum alone does not preserve a constant after zero insertion.
The derivation assumes the retained samples occupy the even positions of the output grid and ignores image boundaries. Centered chroma can require a different alignment, and finite images require an edge rule. The Microsoft example specifies progressive scanning, interpolation and edge handling explicitly.[ref]
Recommended 8-Bit YUV Formats for Video Rendering by Gary Sullivan and Stephen Estrop. 4:2:0-to4:2:2 method and edge equations
Upsampling quality therefore depends on chroma sample location, filter choice and boundary treatment, rather than only on output dimensions. NV12M 2026-11-05
NV12M is the non-contiguous-memory variant of NV12 in the Linux video API. It stores eight-bit luma separately from an interleaved Cb, Cr plane, using 4:2:0 chroma subsampling. Its two image memory planes can occupy independent allocations; the second plane's address is not inferred by adding the first plane's size.[ref]
Planar YUV formats in the Linux Kernel documentation. Semi-Planar table and NV12/NV21/NV12M/NV21M subsection
For an original address example, stipulate an accepted width-six, height-four layout. Let the luma base be 1000 with framebuffer stride eight bytes, and the colour-difference base be 8000 with stride 12 bytes. The allocations occupy and bytes, respectively. Their 56 allocated bytes contain 36 active samples, with padding accounting for the difference.
At zero-based luma position , the address is . In the declared subsampling grid, its associated colour-difference cell is . The Cb address is , and Cr is at 8017. Substituting 1032 for the second base would access an unrelated region under these stipulated allocations.
The V4L2 multi-planar API describes each memory plane explicitly. It also supports single-planar formats, so using that API does not itself prove that a buffer is NV12M. The negotiated pixel format, plane addresses, sizes and strides must agree.[ref]
Single- and multi-planar APIs in the Linux Kernel documentation. §1.26, especially Multi-planar formats
This separation changes buffer organization, not the YCbCr matrix, code ranges or chroma sample location. Those remain additional information needed for colour interpretation and chroma reconstruction.
Stephen Estrop 2026-11-05
Stephen Estrop coauthored Microsoft's Recommended 8-Bit YUV Formats for Video Rendering by Gary Sullivan and Stephen Estrop with Gary Sullivan. The article is dated April2002, updated November2008, and specifies sample grids and memory layouts for eight-bit video rendering.[ref]
An original address calculation illustrates why a pixel format needs more than a sample count. Stipulate an NV12 image of width 10 and height 6, with framebuffer stride 16 bytes in both planes. Let the first luma byte have address 2000, and place the interleaved colour-difference plane immediately after the six stored luma rows. Its base is . The allocation holds bytes, although active samples require only bytes.
At zero-based row 5, column 9, the luma byte is at . Its associated subsampled grid cell is row 2, column 4, whose Cb and Cr bytes are at and 2137. Counting active samples as if they were the allocation size would give the wrong plane base. The shared technical article defines NV12's component order; the chosen dimensions, padding and addresses here are illustrative.[ref]
These calculations locate stored samples. Reconstructing colour additionally requires chroma sample location, chroma reconstruction and the specified YCbCr conversion. The article's joint byline does not identify which coauthor designed an individual format.
V4L2 multi-planar API 2026-11-05
The V4L2 multi-planar API is the Video4Linux interface for describing video buffers whose data may occupy several image memory planes. A buffer acts as a container, while per-plane descriptors identify the relevant storage. This supports formats such as NV12M and NV21M without assuming that one plane immediately follows another.[ref]
Single- and multi-planar APIs in the Linux Kernel documentation. §1.26, discontiguous frame storage and interface extensions
A multi-planar interface and a multi-planar format are different choices. The interface can also carry supported single-planar formats when described through its structures; the reverse interface cannot describe a multi-planar format. Buffer-type names ending in
_MPLANE identify the multi-planar interface, rather than specifying a colour model or sampling ratio.[ref]Single- and multi-planar APIs in the Linux Kernel documentation. §1.26.1, API versus format; opening buffer-type description
A practical interpretation depends on the structure being read. In
v4l2_buffer, length means a number of plane-array elements under the multi-planar API. Inside a V4L2 plane descriptor, length instead means that plane's allocation size in bytes.[ref]For an original descriptor example, a frame with two planes has a container plane count of two and stipulated plane capacities4096 and2048 bytes. Treating the outer count as a two-byte storage capacity, or treating4096 as the number of plane descriptors, confuses quantities with different meanings. The sum6144 describes those declared capacities, not the number of active image bytes.
The negotiated pixel format still determines the component arrangement. Descriptors for two planes could represent a luma plane plus interleaved colour differences; they do not automatically mean one red plane and one green plane. Framebuffer stride, sample encoding and chroma sample location remain part of interpreting the image.
