Documentation/userspace-api/media/v4l/pixfmt-v4l2.rst

   1 .. Permission is granted to copy, distribute and/or modify this
   2 .. document under the terms of the GNU Free Documentation License,
   3 .. Version 1.1 or any later version published by the Free Software
   4 .. Foundation, with no Invariant Sections, no Front-Cover Texts
   5 .. and no Back-Cover Texts. A copy of the license is included at
   6 .. Documentation/userspace-api/media/fdl-appendix.rst.
   7 ..
   8 .. TODO: replace it to GFDL-1.1-or-later WITH no-invariant-sections
   9
  10 ******************************
  11 Single-planar format structure
  12 ******************************
  13
  14 .. tabularcolumns:: |p{4.0cm}|p{2.5cm}|p{11.0cm}|
  15
  16 .. c:type:: v4l2_pix_format
  17
  18 .. cssclass:: longtable
  19
  20 .. flat-table:: struct v4l2_pix_format
  21     :header-rows:  0
  22     :stub-columns: 0
  23     :widths:       1 1 2
  24
  25     * - __u32
  26       - ``width``
  27       - Image width in pixels.
  28     * - __u32
  29       - ``height``
  30       - Image height in pixels. If ``field`` is one of ``V4L2_FIELD_TOP``,
  31         ``V4L2_FIELD_BOTTOM`` or ``V4L2_FIELD_ALTERNATE`` then height
  32         refers to the number of lines in the field, otherwise it refers to
  33         the number of lines in the frame (which is twice the field height
  34         for interlaced formats).
  35     * - :cspan:`2` Applications set these fields to request an image
  36         size, drivers return the closest possible values. In case of
  37         planar formats the ``width`` and ``height`` applies to the largest
  38         plane. To avoid ambiguities drivers must return values rounded up
  39         to a multiple of the scale factor of any smaller planes. For
  40         example when the image format is YUV 4:2:0, ``width`` and
  41         ``height`` must be multiples of two.
  42
  43         For compressed formats that contain the resolution information encoded
  44         inside the stream, when fed to a stateful mem2mem decoder, the fields
  45         may be zero to rely on the decoder to detect the right values. For more
  46         details see :ref:`decoder` and format descriptions.
  47     * - __u32
  48       - ``pixelformat``
  49       - The pixel format or type of compression, set by the application.
  50         This is a little endian
  51         :ref:`four character code <v4l2-fourcc>`. V4L2 defines standard
  52         RGB formats in :ref:`pixfmt-rgb`, YUV formats in
  53         :ref:`yuv-formats`, and reserved codes in
  54         :ref:`reserved-formats`
  55     * - __u32
  56       - ``field``
  57       - Field order, from enum :c:type:`v4l2_field`.
  58         Video images are typically interlaced. Applications can request to
  59         capture or output only the top or bottom field, or both fields
  60         interlaced or sequentially stored in one buffer or alternating in
  61         separate buffers. Drivers return the actual field order selected.
  62         For more details on fields see :ref:`field-order`.
  63     * - __u32
  64       - ``bytesperline``
  65       - Distance in bytes between the leftmost pixels in two adjacent
  66         lines.
  67     * - :cspan:`2`
  68
  69         Both applications and drivers can set this field to request
  70         padding bytes at the end of each line. Drivers however may ignore
  71         the value requested by the application, returning ``width`` times
  72         bytes per pixel or a larger value required by the hardware. That
  73         implies applications can just set this field to zero to get a
  74         reasonable default.
  75
  76         Video hardware may access padding bytes, therefore they must
  77         reside in accessible memory. Consider cases where padding bytes
  78         after the last line of an image cross a system page boundary.
  79         Input devices may write padding bytes, the value is undefined.
  80         Output devices ignore the contents of padding bytes.
  81
  82         When the image format is planar the ``bytesperline`` value applies
  83         to the first plane and is divided by the same factor as the
  84         ``width`` field for the other planes. For example the Cb and Cr
  85         planes of a YUV 4:2:0 image have half as many padding bytes
  86         following each line as the Y plane. To avoid ambiguities drivers
  87         must return a ``bytesperline`` value rounded up to a multiple of
  88         the scale factor.
  89
  90         For compressed formats the ``bytesperline`` value makes no sense.
  91         Applications and drivers must set this to 0 in that case.
  92     * - __u32
  93       - ``sizeimage``
  94       - Size in bytes of the buffer to hold a complete image, set by the
  95         driver. Usually this is ``bytesperline`` times ``height``. When
  96         the image consists of variable length compressed data this is the
  97         number of bytes required by the codec to support the worst-case
  98         compression scenario.
  99
 100         The driver will set the value for uncompressed images.
 101
 102         Clients are allowed to set the sizeimage field for variable length
 103         compressed data flagged with ``V4L2_FMT_FLAG_COMPRESSED`` at
 104         :ref:`VIDIOC_ENUM_FMT`, but the driver may ignore it and set the
 105         value itself, or it may modify the provided value based on
 106         alignment requirements or minimum/maximum size requirements.
 107         If the client wants to leave this to the driver, then it should
 108         set sizeimage to 0.
 109     * - __u32
 110       - ``colorspace``
 111       - Image colorspace, from enum :c:type:`v4l2_colorspace`.
 112         This information supplements the ``pixelformat`` and must be set
 113         by the driver for capture streams and by the application for
 114         output streams, see :ref:`colorspaces`.
 115     * - __u32
 116       - ``priv``
 117       - This field indicates whether the remaining fields of the
 118         struct :c:type:`v4l2_pix_format`, also called the
 119         extended fields, are valid. When set to
 120         ``V4L2_PIX_FMT_PRIV_MAGIC``, it indicates that the extended fields
 121         have been correctly initialized. When set to any other value it
 122         indicates that the extended fields contain undefined values.
 123
 124         Applications that wish to use the pixel format extended fields
 125         must first ensure that the feature is supported by querying the
 126         device for the :ref:`V4L2_CAP_EXT_PIX_FORMAT <querycap>`
 127         capability. If the capability isn't set the pixel format extended
 128         fields are not supported and using the extended fields will lead
 129         to undefined results.
 130
 131         To use the extended fields, applications must set the ``priv``
 132         field to ``V4L2_PIX_FMT_PRIV_MAGIC``, initialize all the extended
 133         fields and zero the unused bytes of the
 134         struct :c:type:`v4l2_format` ``raw_data`` field.
 135
 136         When the ``priv`` field isn't set to ``V4L2_PIX_FMT_PRIV_MAGIC``
 137         drivers must act as if all the extended fields were set to zero.
 138         On return drivers must set the ``priv`` field to
 139         ``V4L2_PIX_FMT_PRIV_MAGIC`` and all the extended fields to
 140         applicable values.
 141     * - __u32
 142       - ``flags``
 143       - Flags set by the application or driver, see :ref:`format-flags`.
 144     * - union {
 145       - (anonymous)
 146     * - __u32
 147       - ``ycbcr_enc``
 148       - Y'CbCr encoding, from enum :c:type:`v4l2_ycbcr_encoding`.
 149         This information supplements the ``colorspace`` and must be set by
 150         the driver for capture streams and by the application for output
 151         streams, see :ref:`colorspaces`.
 152     * - __u32
 153       - ``hsv_enc``
 154       - HSV encoding, from enum :c:type:`v4l2_hsv_encoding`.
 155         This information supplements the ``colorspace`` and must be set by
 156         the driver for capture streams and by the application for output
 157         streams, see :ref:`colorspaces`.
 158     * - }
 159       -
 160     * - __u32
 161       - ``quantization``
 162       - Quantization range, from enum :c:type:`v4l2_quantization`.
 163         This information supplements the ``colorspace`` and must be set by
 164         the driver for capture streams and by the application for output
 165         streams, see :ref:`colorspaces`.
 166     * - __u32
 167       - ``xfer_func``
 168       - Transfer function, from enum :c:type:`v4l2_xfer_func`.
 169         This information supplements the ``colorspace`` and must be set by
 170         the driver for capture streams and by the application for output
 171         streams, see :ref:`colorspaces`.