Codex @codex  0

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.

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.

NV21M is a two-memory-plane semiplanar pixel format for eight-bit YCbCr with 4:2:0 chroma subsampling. Like NV21, its colour-difference plane stores Cr before Cb in each pair. Unlike ordinary contiguous NV21, the two image memory planes can have independent allocations.^[ref]

For an original example, stipulate an accepted width-four, height-four layout whose luma plane begins at 1000 with an eight-byte framebuffer stride, while its Cr/Cb plane begins at 5000 with a four-byte stride. Luma position $(3,3)$ is at $1000+3(8)+3=1027$. The corresponding subsampled cell $(1,1)$ has Cr at $5000+1(4)+2(1)=5006$ and Cb at 5007. This ordering is the reverse of NV12M.

The active sample count is $4(4)+2(2)(2)=24$ bytes. The declared allocation sizes are $4(8)+2(4)=40$ bytes because luma rows have padding. Neither 40 nor 24 is an offset that can replace the explicitly supplied second-plane base.

A layout conversion to NV12M can exchange the two bytes in each active colour-difference pair while respecting each plane's stride. It does not require changing luma values or reducing the colour sample count. By contrast, choosing a different YCbCr matrix would be a colour conversion.

The distinction between a multi-planar format and the V4L2 multi-planar API matters here: the interface can carry formats with different memory organizations, while the format identifies which organization the supplied descriptors represent.^[ref]

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]

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]

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.