1.. -*- coding: utf-8; mode: rst -*- 2 3****************************** 4Single-planar format structure 5****************************** 6 7.. tabularcolumns:: |p{4.0cm}|p{2.5cm}|p{11.0cm}| 8 9.. c:type:: v4l2_pix_format 10 11.. cssclass:: longtable 12 13.. flat-table:: struct v4l2_pix_format 14 :header-rows: 0 15 :stub-columns: 0 16 :widths: 1 1 2 17 18 * - __u32 19 - ``width`` 20 - Image width in pixels. 21 * - __u32 22 - ``height`` 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. 35 * - __u32 36 - ``pixelformat`` 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` 43 * - enum :c:type::`v4l2_field` 44 - ``field`` 45 - Video images are typically interlaced. Applications can request to 46 capture or output only the top or bottom field, or both fields 47 interlaced or sequentially stored in one buffer or alternating in 48 separate buffers. Drivers return the actual field order selected. 49 For more details on fields see :ref:`field-order`. 50 * - __u32 51 - ``bytesperline`` 52 - Distance in bytes between the leftmost pixels in two adjacent 53 lines. 54 * - :cspan:`2` 55 56 Both applications and drivers can set this field to request 57 padding bytes at the end of each line. Drivers however may ignore 58 the value requested by the application, returning ``width`` times 59 bytes per pixel or a larger value required by the hardware. That 60 implies applications can just set this field to zero to get a 61 reasonable default. 62 63 Video hardware may access padding bytes, therefore they must 64 reside in accessible memory. Consider cases where padding bytes 65 after the last line of an image cross a system page boundary. 66 Input devices may write padding bytes, the value is undefined. 67 Output devices ignore the contents of padding bytes. 68 69 When the image format is planar the ``bytesperline`` value applies 70 to the first plane and is divided by the same factor as the 71 ``width`` field for the other planes. For example the Cb and Cr 72 planes of a YUV 4:2:0 image have half as many padding bytes 73 following each line as the Y plane. To avoid ambiguities drivers 74 must return a ``bytesperline`` value rounded up to a multiple of 75 the scale factor. 76 77 For compressed formats the ``bytesperline`` value makes no sense. 78 Applications and drivers must set this to 0 in that case. 79 * - __u32 80 - ``sizeimage`` 81 - Size in bytes of the buffer to hold a complete image, set by the 82 driver. Usually this is ``bytesperline`` times ``height``. When 83 the image consists of variable length compressed data this is the 84 maximum number of bytes required to hold an image. 85 * - enum :c:type:`v4l2_colorspace` 86 - ``colorspace`` 87 - This information supplements the ``pixelformat`` and must be set 88 by the driver for capture streams and by the application for 89 output streams, see :ref:`colorspaces`. 90 * - __u32 91 - ``priv`` 92 - This field indicates whether the remaining fields of the 93 struct :c:type:`v4l2_pix_format`, also called the 94 extended fields, are valid. When set to 95 ``V4L2_PIX_FMT_PRIV_MAGIC``, it indicates that the extended fields 96 have been correctly initialized. When set to any other value it 97 indicates that the extended fields contain undefined values. 98 99 Applications that wish to use the pixel format extended fields 100 must first ensure that the feature is supported by querying the 101 device for the :ref:`V4L2_CAP_EXT_PIX_FORMAT <querycap>` 102 capability. If the capability isn't set the pixel format extended 103 fields are not supported and using the extended fields will lead 104 to undefined results. 105 106 To use the extended fields, applications must set the ``priv`` 107 field to ``V4L2_PIX_FMT_PRIV_MAGIC``, initialize all the extended 108 fields and zero the unused bytes of the 109 struct :c:type:`v4l2_format` ``raw_data`` field. 110 111 When the ``priv`` field isn't set to ``V4L2_PIX_FMT_PRIV_MAGIC`` 112 drivers must act as if all the extended fields were set to zero. 113 On return drivers must set the ``priv`` field to 114 ``V4L2_PIX_FMT_PRIV_MAGIC`` and all the extended fields to 115 applicable values. 116 * - __u32 117 - ``flags`` 118 - Flags set by the application or driver, see :ref:`format-flags`. 119 * - enum :c:type:`v4l2_ycbcr_encoding` 120 - ``ycbcr_enc`` 121 - This information supplements the ``colorspace`` and must be set by 122 the driver for capture streams and by the application for output 123 streams, see :ref:`colorspaces`. 124 * - enum :c:type:`v4l2_hsv_encoding` 125 - ``hsv_enc`` 126 - This information supplements the ``colorspace`` and must be set by 127 the driver for capture streams and by the application for output 128 streams, see :ref:`colorspaces`. 129 * - enum :c:type:`v4l2_quantization` 130 - ``quantization`` 131 - This information supplements the ``colorspace`` and must be set by 132 the driver for capture streams and by the application for output 133 streams, see :ref:`colorspaces`. 134 * - enum :c:type:`v4l2_xfer_func` 135 - ``xfer_func`` 136 - This information supplements the ``colorspace`` and must be set by 137 the driver for capture streams and by the application for output 138 streams, see :ref:`colorspaces`. 139