1 .. -*- coding: utf-8; mode: rst -*-
3 ******************************
4 Single-planar format structure
5 ******************************
7 .. tabularcolumns:: |p{4.0cm}|p{2.5cm}|p{11.0cm}|
9 .. c:type:: v4l2_pix_format
11 .. cssclass:: longtable
13 .. flat-table:: struct v4l2_pix_format
20 - Image width in pixels.
23 - Image height in pixels. If ``field`` is one of ``V4L2_FIELD_TOP``,
24 ``V4L2_FIELD_BOTTOM`` or ``V4L2_FIELD_ALTERNATE`` then height
25 refers to the number of lines in the field, otherwise it refers to
26 the number of lines in the frame (which is twice the field height
27 for interlaced formats).
28 * - :cspan:`2` Applications set these fields to request an image
29 size, drivers return the closest possible values. In case of
30 planar formats the ``width`` and ``height`` applies to the largest
31 plane. To avoid ambiguities drivers must return values rounded up
32 to a multiple of the scale factor of any smaller planes. For
33 example when the image format is YUV 4:2:0, ``width`` and
34 ``height`` must be multiples of two.
37 - The pixel format or type of compression, set by the application.
38 This is a little endian
39 :ref:`four character code <v4l2-fourcc>`. V4L2 defines standard
40 RGB formats in :ref:`rgb-formats`, YUV formats in
41 :ref:`yuv-formats`, and reserved codes in
42 :ref:`reserved-formats`
45 - Field order, from enum :c:type:`v4l2_field`.
46 Video images are typically interlaced. Applications can request to
47 capture or output only the top or bottom field, or both fields
48 interlaced or sequentially stored in one buffer or alternating in
49 separate buffers. Drivers return the actual field order selected.
50 For more details on fields see :ref:`field-order`.
53 - Distance in bytes between the leftmost pixels in two adjacent
57 Both applications and drivers can set this field to request
58 padding bytes at the end of each line. Drivers however may ignore
59 the value requested by the application, returning ``width`` times
60 bytes per pixel or a larger value required by the hardware. That
61 implies applications can just set this field to zero to get a
64 Video hardware may access padding bytes, therefore they must
65 reside in accessible memory. Consider cases where padding bytes
66 after the last line of an image cross a system page boundary.
67 Input devices may write padding bytes, the value is undefined.
68 Output devices ignore the contents of padding bytes.
70 When the image format is planar the ``bytesperline`` value applies
71 to the first plane and is divided by the same factor as the
72 ``width`` field for the other planes. For example the Cb and Cr
73 planes of a YUV 4:2:0 image have half as many padding bytes
74 following each line as the Y plane. To avoid ambiguities drivers
75 must return a ``bytesperline`` value rounded up to a multiple of
78 For compressed formats the ``bytesperline`` value makes no sense.
79 Applications and drivers must set this to 0 in that case.
82 - Size in bytes of the buffer to hold a complete image, set by the
83 driver. Usually this is ``bytesperline`` times ``height``. When
84 the image consists of variable length compressed data this is the
85 maximum number of bytes required to hold an image.
88 - Image colorspace, from enum :c:type:`v4l2_colorspace`.
89 This information supplements the ``pixelformat`` and must be set
90 by the driver for capture streams and by the application for
91 output streams, see :ref:`colorspaces`.
94 - This field indicates whether the remaining fields of the
95 struct :c:type:`v4l2_pix_format`, also called the
96 extended fields, are valid. When set to
97 ``V4L2_PIX_FMT_PRIV_MAGIC``, it indicates that the extended fields
98 have been correctly initialized. When set to any other value it
99 indicates that the extended fields contain undefined values.
101 Applications that wish to use the pixel format extended fields
102 must first ensure that the feature is supported by querying the
103 device for the :ref:`V4L2_CAP_EXT_PIX_FORMAT <querycap>`
104 capability. If the capability isn't set the pixel format extended
105 fields are not supported and using the extended fields will lead
106 to undefined results.
108 To use the extended fields, applications must set the ``priv``
109 field to ``V4L2_PIX_FMT_PRIV_MAGIC``, initialize all the extended
110 fields and zero the unused bytes of the
111 struct :c:type:`v4l2_format` ``raw_data`` field.
113 When the ``priv`` field isn't set to ``V4L2_PIX_FMT_PRIV_MAGIC``
114 drivers must act as if all the extended fields were set to zero.
115 On return drivers must set the ``priv`` field to
116 ``V4L2_PIX_FMT_PRIV_MAGIC`` and all the extended fields to
120 - Flags set by the application or driver, see :ref:`format-flags`.
126 - Y'CbCr encoding, from enum :c:type:`v4l2_ycbcr_encoding`.
127 This information supplements the ``colorspace`` and must be set by
128 the driver for capture streams and by the application for output
129 streams, see :ref:`colorspaces`.
132 - HSV encoding, from enum :c:type:`v4l2_hsv_encoding`.
133 This information supplements the ``colorspace`` and must be set by
134 the driver for capture streams and by the application for output
135 streams, see :ref:`colorspaces`.
141 - Quantization range, from enum :c:type:`v4l2_quantization`.
142 This information supplements the ``colorspace`` and must be set by
143 the driver for capture streams and by the application for output
144 streams, see :ref:`colorspaces`.
147 - Transfer function, from enum :c:type:`v4l2_xfer_func`.
148 This information supplements the ``colorspace`` and must be set by
149 the driver for capture streams and by the application for output
150 streams, see :ref:`colorspaces`.