--- title: "NV12 Video Gives Luma and Chroma Different Sample Grids" description: "Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21." canonical: "https://www.leviathansystems.co/articles/vision-ai-nv12-luma-chroma-sample-grids" last-updated: "2026-10-21" --- # NV12 Video Gives Luma and Chroma Different Sample Grids Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21. NV12 supplies a full luma grid and two smaller chroma grids carried in two planes. It does not supply an RGB triplet at every image position. Compare the offered sample grids, chroma pair order and color interpretation with the receiving AI path's required representation, then identify who supplies any conversion between them. A usable video buffer and a complete model input are different handoffs. ## Two planes carry three components Use the Linux 6.18 V4L2 definition for this comparison. NV12 is linear, contiguous, 8-bit semi-planar 4:2:0: the first plane holds luma, Y', and the second holds interleaved Cb and Cr. Chroma has half the luma sampling resolution horizontally and vertically. A plane is a storage region; a component is a kind of value. The chroma plane contains both Cb and Cr, so two planes do not mean two components. Nor does the second plane provide another full luma-sized grid. These distinctions matter when a proposal describes an image only by its width, height and number of planes. References: [K1](https://www.kernel.org/doc/html/v6.18/userspace-api/media/v4l/pixfmt-yuv-planar.html), [M1](https://learn.microsoft.com/en-us/windows/win32/medfound/recommended-8-bit-yuv-formats-for-video-rendering) ## NV64: 24 luma values and two six-value chroma grids Consider original fictional case NV64: a 6 x 4 image stored as tightly packed NV12, with one byte per component sample and no row padding. Its four luma rows each contain six Y' values, giving 6 x 4 = 24 luma samples and 24 bytes. Each chroma component has a 3 x 2 grid: six Cb values and six Cr values. Interleaving them puts three Cb/Cr pairs in each chroma row. Each row therefore contains six bytes, and the two chroma rows occupy 12 bytes. The sample payload totals 24 + 12 = 36 bytes. The chroma row is as wide in bytes as the luma row in this example, even though it contains only three positions for each chroma component. Counting bytes per row without counting the paired components hides that difference. These counts describe the stipulated sample population. They neither locate the chroma samples precisely relative to the luma grid nor define a downsampling filter; they do not establish that each chroma value is the arithmetic mean of a 2 x 2 block. The 36-byte total excludes headers and transport overhead. Padded rows, tiled formats and independently located plane variants need their own layout accounting. References: [K1](https://www.kernel.org/doc/html/v6.18/userspace-api/media/v4l/pixfmt-yuv-planar.html), [M1](https://learn.microsoft.com/en-us/windows/win32/medfound/recommended-8-bit-yuv-formats-for-video-rendering) ## NV12 versus NV21 changes meaning without changing the byte count Stipulate that NV64's first two chroma bytes, immediately after its 24 luma bytes, are 110 and 150 in that order. Read as NV12, they mean Cb = 110 and Cr = 150. Read as NV21, the same bytes mean Cr = 110 and Cb = 150. Both interpretations retain the 6 x 4 dimensions, the two planes and the 36-byte sample payload. A byte-count check cannot distinguish them. Merely changing the format label does not reorder the contents to preserve their original component meanings. The useful provider response identifies which format describes the actual delivered bytes. An RGB conversion receiving the wrong pair interpretation starts with different chroma inputs, even when every byte is present. References: [K1](https://www.kernel.org/doc/html/v6.18/userspace-api/media/v4l/pixfmt-yuv-planar.html) ## A 72-component RGB return requires a described conversion Now stipulate a receiving path that requires RGB at every position of the same 6 x 4 image, with no crop or resize. Define its return here as three 8-bit components per position in red, green, blue order, with no alpha or padding. It contains 24 x 3 = 72 component values and 72 bytes of component payload. NV64's 36 bytes cannot meet that requirement by being renamed or reshaped. The source holds Y', Cb and Cr with unequal grids; the target holds R, G and B on a common grid. The conversion must account for chroma reconstruction and the declared color interpretation. Those tasks may be combined in an implementation; this explanation does not require a separate intermediate image allocation. Microsoft's historical video-rendering guidance treats chroma sampling-rate conversion and YUV-to-RGB conversion separately. That distinction explains the missing work without choosing its Windows defaults or an interpolation method for this Linux example. The 72 output components do not establish 72 independent source observations or a full-resolution source chroma measurement at every position. They are values in the derived representation. Their numerical results depend on the specified conversion; the counts and first pair do not determine an RGB triplet. The 72 / 36 = 2 payload ratio also says nothing by itself about conversion latency, working memory or AI accuracy. References: [M1](https://learn.microsoft.com/en-us/windows/win32/medfound/recommended-8-bit-yuv-formats-for-video-rendering) ## Pair order leaves color encoding, range and transfer unresolved Linux 6.18 describes V4L2 color interpretation with four values: colorspace, transfer function, Y'CbCr encoding and quantization. The colorspace selects defaults; the other fields can identify alternatives. A useful offer states the resulting interpretation, including any defaults on which it relies. These declarations answer different questions. Y'CbCr encoding identifies the component relationship used for color conversion. Quantization identifies how the component ranges map to stored codes. The transfer function concerns the relationship between encoded and linear-light values. Correct Cb/Cr order leaves all of those questions to be resolved. For NV64, do not infer BT.601, BT.709, full range, limited range or sRGB from the NV12 label. Likewise, an RGB return needs its own color description. The related sRGB arithmetic guide explains why scaling channel codes to 0-1 does not, by itself, produce linear-light RGB. References: [K2](https://www.kernel.org/doc/html/v6.18/userspace-api/media/v4l/colorspaces-defs.html) ## Compare the offers at the required consumer Suppose fictional offer A ends at NV64's 36-byte NV12 return and supplies its dimensions, layout, pair order and color interpretation. If the appointed receiving application accepts that declared NV12 representation, A addresses the representation requirement on paper. An RGB conversion need not be added merely to increase the component count. For the stipulated 72-component RGB consumer, A stops earlier. Its proposal needs to identify the software provider responsible for the remaining conversion, its implementation and revision, the applicable chroma sample siting and reconstruction treatment, and the resulting RGB layout and numerical encoding. The buyer then knows which work is included and which work remains. Offer B includes that conversion and delivers the required 6 x 4 RGB array. For a concrete comparison, stipulate a source with Rec. 709 chromaticities and transfer function, BT.709 Y'CbCr encoding and full-range quantization, and a consumer requiring full-range, Rec. 709 encoded RGB in the previously defined 8-bit R, G, B order. These are fictional requirements, not properties inferred from NV12. A useful B response connects those source declarations to the consumer's specified RGB representation, identifies the applicable chroma sample siting and the reconstruction and conversion implementation, and includes the 72-component return in its scope. That addresses the requested representation more completely than A's NV12-only return. A plus an explicitly assigned conversion can address the same requirement. These are proposal comparisons, not observed conversion results or application acceptance. If either offer also claims shared-buffer delivery, use the related DMA-BUF guide for layout compatibility, imports, completed production and reuse. Those checks concern access to the image; the present comparison concerns which image values the consumer receives. The Bayer guide separately explains filtered sensor samples and demosaiced RGB, before this video-representation question. References: [K2](https://www.kernel.org/doc/html/v6.18/userspace-api/media/v4l/colorspaces-defs.html), [M1](https://learn.microsoft.com/en-us/windows/win32/medfound/recommended-8-bit-yuv-formats-for-video-rendering) ## Discuss physical deployment when the selected equipment needs it If the selected video-processing equipment also needs receiving, rack integration, onsite installation or IT cabling, Leviathan's Complete Physical Deployment service provides a route to discuss that physical package. Use the related service and project inquiry with a nonconfidential equipment list, site requirements, connections and physical handoff needs to establish scope and availability. Image conversion, camera or codec integration, model preprocessing and application acceptance remain with the appointed software and imaging providers. References: [L1](https://www.leviathansystems.co/services/turnkey-gpu-deployment) ## Primary sources - [K1 — Linux 6.18: Planar YUV formats — NV12, NV21, NV12M and NV21M](https://www.kernel.org/doc/html/v6.18/userspace-api/media/v4l/pixfmt-yuv-planar.html). Checked 2026-10-21. Planar introduction, semi-planar overview and NV12/NV21 subsection define component storage, 8-bit 4:2:0 sampling and pair order. NV64 applies these definitions to an original, tightly packed 6 x 4 example. - [K2 — Linux 6.18: Defining Colorspaces in V4L2](https://www.kernel.org/doc/html/v6.18/userspace-api/media/v4l/colorspaces-defs.html). Checked 2026-10-21. Defines colorspace, transfer-function, Y'CbCr-encoding and quantization declarations and their defaults. Supports the distinction between storage format and numerical interpretation. - [M1 — Microsoft: Recommended 8-Bit YUV Formats for Video Rendering](https://learn.microsoft.com/en-us/windows/win32/medfound/recommended-8-bit-yuv-formats-for-video-rendering). Checked 2026-10-21. Historical Windows guidance, authored April 2002 and updated November 2008: introduction, sampling, NV12 surface description and conversion discussion. Used to explain reduced chroma sampling and reconstruction versus color conversion; Linux 6.18 defines the named format in NV64. - [L1 — Leviathan Systems: Complete Physical Deployment](https://www.leviathansystems.co/services/turnkey-gpu-deployment). Checked 2026-10-21. Describes a separately agreed physical package covering equipment receiving, rack integration, onsite deployment and cabling, with project requirements and availability confirmed. ## Related Leviathan resources - [Bayer samples and derived RGB components](/articles/industrial-vision-bayer-samples-derived-rgb-components) - [Normalized sRGB and linear-light arithmetic](/articles/vision-ai-srgb-linear-light-arithmetic) - [DMA-BUF layout compatibility and completed work](/articles/dma-buf-image-sharing-layout-completion) - [Complete Physical Deployment](/services/turnkey-gpu-deployment) - [Discuss physical installation for the selected equipment](/contact?service=turnkey-gpu-deployment&from=%2Farticles%2Fvision-ai-nv12-luma-chroma-sample-grids) ## Does the selected equipment need physical deployment? Share a nonconfidential equipment, site, connection and physical handoff outline to discuss installation scope, requirements and availability. [Discuss the scope](/contact?service=turnkey-gpu-deployment&from=/articles/vision-ai-nv12-luma-chroma-sample-grids)