Chapter 2. Image Formats
Prev | Part I. Video for Linux Two API Specification | Next

## Chapter 2. Image Formats

The V4L2 API was primarily designed for devices exchanging image data with applications. The v4l2_pix_format and v4l2_pix_format_mplane structures define the format and layout of an image in memory. The former is used with the single-planar API, while the latter is used with the multi-planar version (see the section called “Single- and multi-planar APIs”). Image formats are negotiated with the `VIDIOC_S_FMT` ioctl. (The explanations here focus on video capturing and output, for overlay frame buffer formats see also `VIDIOC_G_FBUF`.)

## Single-planar format structure

Table 2.1. struct v4l2_pix_format

__u32 | `width` | Image width in pixels.
__u32 | `height` | Image height in pixels.
Applications set these fields to request an image size, drivers return the closest possible values. In case of planar formats the `width` and `height` applies to the largest plane. To avoid ambiguities drivers must return values rounded up to a multiple of the scale factor of any smaller planes. For example when the image format is YUV 4:2:0, `width` and `height` must be multiples of two.
__u32 | `pixelformat` | The pixel format or type of compression, set by the application. This is a little endian four character code. V4L2 defines standard RGB formats in Table 2.6, “Packed RGB Image Formats”, YUV formats in the section called “YUV Formats”, and reserved codes in Table 2.10, “Reserved Image Formats”
enum v4l2_field | `field` | Video images are typically interlaced. Applications can request to capture or output only the top or bottom field, or both fields interlaced or sequentially stored in one buffer or alternating in separate buffers. Drivers return the actual field order selected. For details see the section called “Field Order”.
__u32 | `bytesperline` | Distance in bytes between the leftmost pixels in two adjacent lines.

Both applications and drivers can set this field to request padding bytes at the end of each line. Drivers however may ignore the value requested by the application, returning `width` times bytes per pixel or a larger value required by the hardware. That implies applications can just set this field to zero to get a reasonable default.

Video hardware may access padding bytes, therefore they must reside in accessible memory. Consider cases where padding bytes after the last line of an image cross a system page boundary. Input devices may write padding bytes, the value is undefined. Output devices ignore the contents of padding bytes.

When the image format is planar the `bytesperline` value applies to the largest plane and is divided by the same factor as the `width` field for any smaller planes. For example the Cb and Cr planes of a YUV 4:2:0 image have half as many padding bytes following each line as the Y plane. To avoid ambiguities drivers must return a `bytesperline` value rounded up to a multiple of the scale factor.

__u32 | `sizeimage` | Size in bytes of the buffer to hold a complete image, set by the driver. Usually this is `bytesperline` times `height`. When the image consists of variable length compressed data this is the maximum number of bytes required to hold an image.
enum v4l2_colorspace | `colorspace` | This information supplements the `pixelformat` and must be set by the driver, see the section called “Colorspaces”.
__u32 | `priv` | Reserved for custom (driver defined) additional information about formats. When not used drivers and applications must set this field to zero.

Prev | Up | Next
Streaming Parameters | Home | Multi-planar format structures