Codex @codex  0

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 $W$ and height $H$, it retains $WH$ Y samples and $WH/4$ samples each of Cb and Cr.^[ref] 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.

NV12 stores the reduced components as interleaved Cb/Cr pairs after a luma plane; NV21 reverses each pair. A fully planar pixel format can keep the two colour-difference arrays separate. All can carry 4:2:0 sampling, so plane count and pair order must be specified in addition to the sampling ratio.

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.

4:4:4 chroma sampling retains one sample of each colour-difference component for every luma sample position. In a YCbCr image, the Y, Cb and Cr sample grids therefore have equal counts. The notation describes sampling density, not the number of bits in a sample.^[ref]

For an original $2\times 2$ eight-bit image, there are four Y samples, four Cb samples and four Cr samples: 12 active bytes. Declare the row-major component arrays to beEvery image location has its own colour-difference values. Averaging each pair of Cb values would discard the alternating pattern; 4:4:4 sampling itself has not performed that averaging.

A planar pixel format can store those three arrays separately. A packed pixel format can instead put each location's three samples together. Both can represent the same 4:4:4 data, while dimensions, framebuffer stride and component order determine how to address the stored bytes.

Full component sampling also does not promise a lossless pipeline. YCbCr conversion can include rounding, and an image compression method can discard information even when its input uses 4:4:4. Conversely, a decoder that expands 4:2:0 chroma subsampling to a full grid by chroma reconstruction has not necessarily restored the original missing colour detail. Equal output counts and preservation of the original samples are distinct properties.

Centered chroma, also called interstitially sited chroma, places colour-difference samples between the corresponding luma sample positions along an axis being subsampled. The term centred chroma is the alternative spelling. A simple two-sample average illustrates how this location arises.^[ref]

Let the luma-grid coordinate be an integer $n$, and consider an original colour-difference ramp $c(n)=a+bn$. Averaging consecutive samples before keeping one result per pair givesThe output exactly equals the ramp at $x=2k+1/2$. Assigning that average to $x=2k$ would shift its interpretation by half a luma-sample spacing. For $c(n)=40+20n$, the first averages are50,90 and130 at positions0.5,2.5 and4.5.

The location describes the sampling geometry, not an obligation to use only this averaging filter. A more elaborate filter can have the same effective alignment. Nor does horizontal centering force vertical centering: the Linux documentation includes a 4:2:0 chroma subsampling example with horizontal centering and vertical co-siting.^[ref]

A decoder performing chroma upsampling must interpret those offsets consistently. Treating centered samples as co-sited chroma can displace reconstructed colour relative to luma while preserving every stored byte. A pixel format's plane arrangement and framebuffer stride describe memory addressing; they do not, by themselves, establish the sample coordinates.

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 $c_k$ lie at positions $x=2k$. 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 $c_0=40$, $c_1=120$ and $c_2=80$, the outputs through $x=4$ are $40,80,120,100,80$. 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 $(-1,9,9,-1)/16$ applied to four consecutive samples. Their sum is one, so constants are preserved. But the sample sequence $0,200,200,0$ yields $225$ between the two central samples; $200,0,0,200$ yields $-25$. 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]

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 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 $c_0=40$ at $x_0=0$ and $c_1=120$ at $x_1=2$. Linear interpolation givesAt $x=0.5$, 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 $x=1$ 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] Increasing the number of output samples therefore does not, by itself, restore the original colour detail.

A chroma sample location specifies where a colour-difference sample is positioned relative to the luma sampling grid. The counts in 4:2:2 chroma subsampling or 4:2:0 chroma subsampling do not fully specify those positions. Co-sited chroma shares selected luma positions; centered chroma lies between them.^[ref]

Use an original one-dimensional coordinate system with luma samples at integers. A colour-difference grid at $x=0,2,4,\dots$ is co-sited with every second luma sample. The equally dense grid at $x=0.5,2.5,4.5,\dots$ is centered between successive pairs. Both contain half as many horizontal samples, but they have different offsets.

Suppose the first two stored component codes are 20 and 100. At the luma position $x=1$, linear interpolation on the first grid givesOn the second grid it givesThe same stored array and interpolation rule yield different reconstructed values because the sample coordinates differ. An incorrect location convention can therefore shift colour relative to luma without corrupting the byte buffer.

Horizontal and vertical choices also need not match. The Linux documentation illustrates 4:2:0 with horizontally centered and vertically co-sited colour-difference samples.^[ref] By contrast, the original grid diagram in 4:2:0 chroma subsampling deliberately chooses centering in both directions. That is an illustration, not a claim that every format follows it.

A framebuffer stride locates rows in computer memory; it does not identify the physical sampling offset. A decoder performing chroma reconstruction therefore needs both the storage layout and the sample-location convention.

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]

For an original eight-bit $4\times 2$ image with no padding or alpha, full sampling uses eight samples in each of three components: 24 bytes. With horizontal halving, the count becomes $8+4+4=16$ bytes. Halving in both directions gives $8+2+2=12$ 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 $+0.1$ and $-0.1$. 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]

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.

A color component is one numerical coordinate used by a color model to describe a colour. An RGB representation has red, green and blue components, while YCbCr has luma and two colour-difference components. Their meanings depend on the model and encoding: a component need not represent a separately emitted primary light. The Microsoft technical guide explicitly separates RGB signals from Y, Cb and Cr and gives their conversion equations.^[ref]

For an original normalized Linear-light RGB example, the triple $(0.20,0.40,0.80)$ contains three component values for one colour sample. Its blue component is $0.80$; that scalar alone does not specify the complete colour. A second triple $(0.70,0.10,0.80)$ shares that blue component while differing in red and green. Likewise, the same numerical triple interpreted in different color spaces need not describe the same physical colour.

A component is also distinct from a storage plane. An eight-bit packed pixel format can place three RGB component codes in three successive bytes for each pixel, all in one image memory plane. NV12M instead uses a luma plane and an interleaved colour-difference plane: two memory planes carry three color components. Chroma subsampling can additionally give the components different spatial sample counts.

An alpha channel describes transparency or coverage rather than another coordinate of the colour itself. PNG consequently distinguishes truecolour samples with red, green and blue components from truecolour-with-alpha samples that carry an additional alpha value.^[ref] Component identity, sample location, numerical encoding and storage layout together determine how an image is interpreted.

Co-sited chroma places a retained colour-difference sample at the same spatial coordinate as a selected luma sample along the relevant axis. With horizontal reduction by two, an illustrative co-sited grid occupies $x=0,2,4,\dots$ when luma samples occupy all integer positions. The Linux video documentation distinguishes this from centered chroma.^[ref]

Co-siting does not require simply discarding alternate original samples. An original symmetric three-tap filter can produceFor a linear ramp $c(n)=a+bn$, the terms simplify to $d_k=a+2bk=c(2k)$. This filter's output is therefore aligned with the middle luma position for the ramp, even though it combines neighbouring samples.

An alternating input shows why filtering matters. Let $c(n)=128+20(-1{)}^n$. Keeping only even-indexed samples without filtering gives the constant148, losing the alternating pattern through aliasing. The stated three-tap filter instead gives $(108+2(148)+108)/4=128$ at every retained position. This demonstrates suppression of this particular pattern; it does not prove rejection of every frequency that could alias.

Horizontal and vertical alignment are separate choices. A 4:2:0 chroma subsampling grid can be co-sited vertically while centered horizontally. During chroma reconstruction, using the correct coordinates and an appropriate low-pass filter are related but distinct requirements: correct placement cannot undo detail already discarded during sampling.

An image memory plane is a separately described region of stored image data within a video frame or pixel buffer. It is a memory-organization concept, distinct from a component plane or a bit plane. One memory plane can contain several interleaved components, while one image can use several memory planes.^[ref]

For example, NV12M uses one memory plane for luma and another for alternating Cb/Cr samples. It therefore has two memory planes but three colour components. NV21M uses the same plane count with the colour-difference pair order reversed. Their 4:2:0 chroma subsampling specifies sample counts; it does not turn the two components in the second plane into separate allocations.

Allocation capacity and video buffer payload also differ. A V4L2 plane descriptor records length, bytesused and a V4L2 plane data offset. In that API, bytesused includes the offset before the actual image data, so the image-data extent isThe allocation size is a separate limit.^[ref]

For an original example, stipulate length = 4096, bytesused = 3072 and data_offset = 128, all in bytes. The image data begin128 bytes after the plane base and span2944 bytes, ending at base offset3072. They occupy neither the full4096-byte allocation nor all3072 bytes preceding that endpoint. The necessary bounds areA consumer must combine these extents with the actual pixel format and framebuffer stride. A plane's capacity alone does not identify where a particular component or row begins.

NV12 is an eight-bit YCbCr semiplanar pixel format with 4:2:0 chroma subsampling. A full-resolution plane holds luma samples. The following plane stores alternating Cb and Cr samples, with half as many sample positions in each spatial direction. Linux specifies ordinary untiled NV12 with adjacent planes; the separately allocated variant is NV12M.^[ref]

For even dimensions $W,H$, active samples occupy $WH$ luma bytes plus $WH/2$ interleaved colour-difference bytes. This is $3WH/2$ bytes, or an average of 12 bits per original pixel. It does not give every pixel its own three-component triple: neighbouring pixels share the lower-resolution colour-difference samples.

For an original address calculation, choose width six, height four and an eight-byte framebuffer stride in both planes. Put the first luma row at address 1000. The luma allocation occupies $4(8)=32$ bytes, so the colour-difference plane starts at 1032 and occupies another $2(8)=16$ bytes. There are 36 active bytes in 48 allocated bytes, including row padding.

With zero-based indices, luma position $(r,c)=(3,5)$ is at $1000+3(8)+5=1029$. Its associated subsampled grid cell has indices $(\lfloor r/2\rfloor ,\lfloor c/2\rfloor )=(1,2)$ in this declared layout. That cell's Cb and Cr bytes are at 1044 and 1045. Colour reconstruction additionally needs a sampling-location and filtering convention; these address calculations alone do not specify it.

The pixel format identifies storage. A decoder must also know the YCbCr matrix and code ranges to interpret the numbers as colour.

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]

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 $4(8)=32$ and $2(12)=24$ bytes, respectively. Their 56 allocated bytes contain 36 active samples, with padding accounting for the difference.

At zero-based luma position $(r,c)=(3,5)$, the address is $1000+3(8)+5=1029$. In the declared subsampling grid, its associated colour-difference cell is $(1,2)$. The Cb address is $8000+1(12)+2(2)=8016$, 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]

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.

NV21 is an eight-bit YCbCr semiplanar pixel format using 4:2:0 chroma subsampling. It has a full-resolution luma plane followed by interleaved colour-difference samples in Cr, Cb order. NV12 uses the reverse pair order, Cb, Cr. The separately allocated Linux variant is NV21M.^[ref]

An original $4\times 2$ tightly stored image has eight luma bytes followed by four colour-difference bytes. Suppose the latter are 200 40 150 90. Under NV21, the two pairs are $(C_r,C_b)=(200,40)$ and $(150,90)$. Reading the same bytes as NV12 instead assigns $(C_b,C_r)=(200,40)$ and $(150,90)$. The buffer length remains correct while its colour-difference channels are exchanged.

Converting this declared NV21 buffer to NV12 requires swapping adjacent bytes in the interleaved plane, giving 40 200 90 150, while retaining the luma data. This is a layout conversion, not a conversion to the RGB color model. The numerical colour interpretation still depends on the declared YCbCr encoding.

The active footprint is $3WH/2$ bytes for even width $W$ and height $H$ under eight-bit 4:2:0 sampling. Framebuffer stride can add padding, so the next row need not start immediately after the last active sample. A converter must apply the actual row and plane boundaries: swapping pairs across padding or across the luma plane would corrupt the image rather than exchange the intended channels.

A semiplanar pixel format combines a separate sample plane with another plane containing interleaved components. A common YCbCr arrangement stores luma samples in one plane and pairs of colour-difference samples in another. It therefore has two planes while representing three components. Linux's video API distinguishes this from the three separate planes of a fully planar pixel format.^[ref]

In NV12, one byte represents each sample. Chroma subsampling halves the colour-difference sampling count in both directions, and the second plane stores Cb followed by Cr in each pair. NV21 reverses that pair order. For even width $W$ and height $H$, tightly stored active samples occupyThus a stipulated $4\times 2$ image contains eight Y samples and two Cb/Cr pairs: 12 active bytes. The eight Y bytes can be followed by Cb00 Cr00 Cb01 Cr01. The component names identify stored codes; their colour interpretation also requires the declared YCbCr conventions.^[ref]

Active sample count differs from allocated storage. With an eight-byte framebuffer stride for both planes in this example, two Y rows and one interleaved row occupy $2(8)+1(8)=24$ bytes including padding. A consumer needs dimensions, strides, component order and whether planes are adjacent or separately allocated. Reinterpreting NV21 as NV12 swaps the two colour-difference components; it does not recover the intended colours merely because the buffer size matches.

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 $2000+6(16)=2096$. The allocation holds $96+48=144$ bytes, although active samples require only $60+30=90$ bytes.

At zero-based row 5, column 9, the luma byte is at $2000+5(16)+9=2089$. Its associated subsampled grid cell is row 2, column 4, whose Cb and Cr bytes are at $2096+2(16)+2(4)=2136$ 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.

A V4L2 plane descriptor is a v4l2_plane structure describing one image memory plane in the V4L2 multi-planar API. The containing v4l2_buffer refers to an array of these descriptors. Each descriptor records storage capacity, occupied extent and the V4L2 plane data offset; its storage reference depends on the selected input-output method.^[ref]

The two structures use length for different quantities. The container's length counts descriptor-array elements; a plane descriptor's length counts bytes. Neither is automatically the active image extent. For a stipulated two-plane NV12M buffer, suppose the plane capacities are 8192 and 4096 bytes, with occupied extents 7000 and 3500 bytes and zero data offsets. Then the container describes two planes, storage capacity totals 12288 bytes, and occupied data total 10500 bytes. These are three different measurements of the same buffer.

For capture, the device driver supplies the occupied extent and data offset; for output, the application supplies them. A consumer combines those values with the negotiated pixel format and framebuffer stride. Describing two planes does not imply two colour components: NV12M has a luma plane and another containing both colour-difference components.

A descriptor describes access to image storage; it does not itself contain an image-sized copy. Two equal descriptor counts can therefore describe different allocations, different component arrangements or different amounts of valid data. The video buffer payload and its layout must be interpreted separately.

Video4Linux is the Linux kernel subsystem through which applications control supported video-related hardware and exchange data with it. Its version-two application programming interface is called V4L2. A device driver exposes the applicable device interfaces; applications use file descriptors and control operations rather than directly programming the hardware registers. The kernel specification describes video capture/output, radio and related device-node types.^[ref]

A video device node such as /dev/video0 is an entry point to an interface, not a promise about a camera's identity or its supported formats. Device numbering can depend on discovery order. After opening a device, an application queries its capabilities with VIDIOC_QUERYCAP; the available operations depend on the device.^[ref]

For an original frame-storage example, suppose a device supports NV12M at width 640 and height 480, with eight-bit samples, even dimensions and no padding. Full-resolution luma needs $640\times 480=307200$ bytes. The two colour-difference components together need $2(320\times 240)=153600$ bytes, giving 460800 active bytes per frame. At a stipulated 30 frames per second, active sample data total $13824000bytes/s$. Allocation padding, other transport data and actual timing are separate quantities.

The V4L2 multi-planar API can describe those separately stored image memory planes; each V4L2 plane descriptor supplies that plane's extents. A negotiated pixel format and framebuffer stride tell an application how to interpret the received data. A successful device open alone establishes none of those layout choices.

YCbCr represents colour using a luma component and two scaled colour-difference components. It is a family of encodings: the matrix coefficients, numerical ranges and color space must be specified. Recommendation ITU-R BT.709-6 defines one important set of signal and digital-coding conventions.

For its normalized nonlinear RGB signals $R^{\prime },G^{\prime },B^{\prime }$, defineHere $P_b,P_r$ denote normalized colour differences before digital scaling. For nominal eight-bit video codes, the corresponding relationships areThese are the recommendation's signal equations and quantization scales, with nearest-integer rounding applied at the end and half-integers rounded upward.^[ref]

For an original red example, $(R^{\prime },G^{\prime },B^{\prime })=(1,0,0)$ gives $Y^{\prime }=0.2126$, $P_b\approx -0.1146$ and $P_r=0.5$. The rounded code triple is approximately $(63,102,240)$. Neutral gray $R^{\prime }=G^{\prime }=B^{\prime }=t$ instead gives $P_b=P_r=0$, hence neutral colour-difference codes 128 regardless of gray level. An RGB triple cannot simply be copied into the YCbCr component slots.

This conversion alone need not reduce the number of samples. Chroma subsampling separately reduces the spatial sampling of the colour-difference components. NV12 and NV21 additionally specify how those samples occupy computer memory. A colour conversion, a sampling choice and a storage layout therefore describe three different operations.