Table of Contents
V4L2_COLORSPACE_SMPTE170M)V4L2_COLORSPACE_REC709)V4L2_COLORSPACE_SRGB)V4L2_COLORSPACE_ADOBERGB)V4L2_COLORSPACE_BT2020)V4L2_COLORSPACE_SMPTE240M)V4L2_COLORSPACE_470_SYSTEM_M)V4L2_COLORSPACE_470_SYSTEM_BG)V4L2_COLORSPACE_JPEG)V4L2_PIX_FMT_YUYV with different order of samples
in memoryV4L2_PIX_FMT_YUYV with different order of samples
in memoryV4L2_PIX_FMT_YUYV with different order of samples
in memoryV4L2_PIX_FMT_YUV420
with planes non contiguous in memory. V4L2_PIX_FMT_YVU420
with planes non contiguous in memory. V4L2_PIX_FMT_YUYVV4L2_PIX_FMT_Y41PV4L2_PIX_FMT_YVU420V4L2_PIX_FMT_NV12 and V4L2_PIX_FMT_NV21 with planes
non contiguous in memory. V4L2_PIX_FMT_NV12 is the memory layout. Pixels are
grouped in macroblocks of 64x32 size. The order of macroblocks in memory is
also not standard.
V4L2_PIX_FMT_YVU420V4L2_PIX_FMT_NV16 and V4L2_PIX_FMT_NV61 with planes
non contiguous in memory. V4L2_PIX_FMT_YVU420The 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.)
Table 2.1. struct v4l2_pix_format
| __u32 | width | Image width in pixels. |
| __u32 | height | Image height in pixels. If field is
one of V4L2_FIELD_TOP, V4L2_FIELD_BOTTOM
or V4L2_FIELD_ALTERNATE then height refers to the
number of lines in the field, otherwise it refers to the number of
lines in the frame (which is twice the field height for interlaced
formats). |
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.16, “Packed RGB Image Formats”, YUV formats in the section called “YUV Formats”, and reserved codes in Table 2.20, “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 more details on fields 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 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
For compressed formats the | ||
| __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 for
capture streams and by the application for output streams,
see the section called “Colorspaces”. |
| __u32 | priv | This field indicates whether the remaining fields of the
v4l2_pix_format structure, also called the extended
fields, are valid. When set to Applications that wish to use the pixel format extended fields must first
ensure that the feature is supported by querying the device for the
To use the extended fields, applications must set the
When the |
| __u32 | flags | Flags set by the application or driver, see Table 2.21, “Format Flags”. |
| enum v4l2_ycbcr_encoding | ycbcr_enc | This information supplements the
colorspace and must be set by the driver for
capture streams and by the application for output streams,
see the section called “Colorspaces”. |
| enum v4l2_quantization | quantization | This information supplements the
colorspace and must be set by the driver for
capture streams and by the application for output streams,
see the section called “Colorspaces”. |