Image memory plane (source code)

= Image memory plane

An \b[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.<Single- and multi-planar APIs in the Linux Kernel documentation>[§1.26, frame planes as sub-buffers]{ref}

For example, <NV12M> uses one memory plane for <luma (video)> 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 is
$$
L_{\mathrm{image}}=\mathrm{bytesused}-\mathrm{data\_offset}.
$$
The allocation size is a separate limit.<Buffers in the Linux Kernel video API documentation>[§3.5.3, v4l2_plane fields and data_offset note]{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 are
$$
0\leq\mathrm{data\_offset}\leq\mathrm{bytesused}\leq\mathrm{length}.
$$
A 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.