V4L2 multi-planar API

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.

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.

The V4L2 plane data offset is the byte distance from the beginning of an image memory plane to its image data. It is the data_offset member of a V4L2 plane descriptor. In this interface, bytesused includes that prefix, so the image-data extent is bytesused - data_offset.^[ref]

Write $d$ for data_offset, $u$ for bytesused and $a$ for the plane's length, all in bytes. A consistent nonnegative extent satisfiesIf $p$ is the mapped plane-base address, the image begins at $p+d$ and ends immediately before $p+u$. This is an offset within a plane, distinct from the descriptor's mem_offset used when arranging a memory mapping.

For an original bounds example, stipulate $a=8192$, $u=6144$ and $d=256$. The image occupies 5888 bytes beginning at byte offset 256. Its last byte is at offset 6143. Taking a length of 6144 from the shifted starting address would instead read through offset 6399, including 256 bytes beyond the declared extent. Conversely, discarding the prefix twice would lose 256 valid bytes.

The offset does not specify framebuffer stride or component order. Once the correct image start is found, the negotiated pixel format still determines how rows and color components are read. A correct extent prevents a boundary mistake; it does not by itself establish that the samples represent the intended image.