Merge remote-tracking branch 'iommu/next'
[deliverable/linux.git] / Documentation / media / uapi / v4l / pixfmt-002.rst
1 .. -*- coding: utf-8; mode: rst -*-
2
3 ******************************
4 Single-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
19 - .. row 1
20
21 - __u32
22
23 - ``width``
24
25 - Image width in pixels.
26
27 - .. row 2
28
29 - __u32
30
31 - ``height``
32
33 - Image height in pixels. If ``field`` is one of ``V4L2_FIELD_TOP``,
34 ``V4L2_FIELD_BOTTOM`` or ``V4L2_FIELD_ALTERNATE`` then height
35 refers to the number of lines in the field, otherwise it refers to
36 the number of lines in the frame (which is twice the field height
37 for interlaced formats).
38
39 - .. row 3
40
41 - :cspan:`2` Applications set these fields to request an image
42 size, drivers return the closest possible values. In case of
43 planar formats the ``width`` and ``height`` applies to the largest
44 plane. To avoid ambiguities drivers must return values rounded up
45 to a multiple of the scale factor of any smaller planes. For
46 example when the image format is YUV 4:2:0, ``width`` and
47 ``height`` must be multiples of two.
48
49 - .. row 4
50
51 - __u32
52
53 - ``pixelformat``
54
55 - The pixel format or type of compression, set by the application.
56 This is a little endian
57 :ref:`four character code <v4l2-fourcc>`. V4L2 defines standard
58 RGB formats in :ref:`rgb-formats`, YUV formats in
59 :ref:`yuv-formats`, and reserved codes in
60 :ref:`reserved-formats`
61
62 - .. row 5
63
64 - enum :c:type::`v4l2_field`
65
66 - ``field``
67
68 - Video images are typically interlaced. Applications can request to
69 capture or output only the top or bottom field, or both fields
70 interlaced or sequentially stored in one buffer or alternating in
71 separate buffers. Drivers return the actual field order selected.
72 For more details on fields see :ref:`field-order`.
73
74 - .. row 6
75
76 - __u32
77
78 - ``bytesperline``
79
80 - Distance in bytes between the leftmost pixels in two adjacent
81 lines.
82
83 - .. row 7
84
85 - :cspan:`2`
86
87 Both applications and drivers can set this field to request
88 padding bytes at the end of each line. Drivers however may ignore
89 the value requested by the application, returning ``width`` times
90 bytes per pixel or a larger value required by the hardware. That
91 implies applications can just set this field to zero to get a
92 reasonable default.
93
94 Video hardware may access padding bytes, therefore they must
95 reside in accessible memory. Consider cases where padding bytes
96 after the last line of an image cross a system page boundary.
97 Input devices may write padding bytes, the value is undefined.
98 Output devices ignore the contents of padding bytes.
99
100 When the image format is planar the ``bytesperline`` value applies
101 to the first plane and is divided by the same factor as the
102 ``width`` field for the other planes. For example the Cb and Cr
103 planes of a YUV 4:2:0 image have half as many padding bytes
104 following each line as the Y plane. To avoid ambiguities drivers
105 must return a ``bytesperline`` value rounded up to a multiple of
106 the scale factor.
107
108 For compressed formats the ``bytesperline`` value makes no sense.
109 Applications and drivers must set this to 0 in that case.
110
111 - .. row 8
112
113 - __u32
114
115 - ``sizeimage``
116
117 - Size in bytes of the buffer to hold a complete image, set by the
118 driver. Usually this is ``bytesperline`` times ``height``. When
119 the image consists of variable length compressed data this is the
120 maximum number of bytes required to hold an image.
121
122 - .. row 9
123
124 - enum :c:type:`v4l2_colorspace`
125
126 - ``colorspace``
127
128 - This information supplements the ``pixelformat`` and must be set
129 by the driver for capture streams and by the application for
130 output streams, see :ref:`colorspaces`.
131
132 - .. row 10
133
134 - __u32
135
136 - ``priv``
137
138 - This field indicates whether the remaining fields of the
139 struct :c:type:`v4l2_pix_format`, also called the
140 extended fields, are valid. When set to
141 ``V4L2_PIX_FMT_PRIV_MAGIC``, it indicates that the extended fields
142 have been correctly initialized. When set to any other value it
143 indicates that the extended fields contain undefined values.
144
145 Applications that wish to use the pixel format extended fields
146 must first ensure that the feature is supported by querying the
147 device for the :ref:`V4L2_CAP_EXT_PIX_FORMAT <querycap>`
148 capability. If the capability isn't set the pixel format extended
149 fields are not supported and using the extended fields will lead
150 to undefined results.
151
152 To use the extended fields, applications must set the ``priv``
153 field to ``V4L2_PIX_FMT_PRIV_MAGIC``, initialize all the extended
154 fields and zero the unused bytes of the
155 struct :c:type:`v4l2_format` ``raw_data`` field.
156
157 When the ``priv`` field isn't set to ``V4L2_PIX_FMT_PRIV_MAGIC``
158 drivers must act as if all the extended fields were set to zero.
159 On return drivers must set the ``priv`` field to
160 ``V4L2_PIX_FMT_PRIV_MAGIC`` and all the extended fields to
161 applicable values.
162
163 - .. row 11
164
165 - __u32
166
167 - ``flags``
168
169 - Flags set by the application or driver, see :ref:`format-flags`.
170
171 - .. row 12
172
173 - enum :c:type:`v4l2_ycbcr_encoding`
174
175 - ``ycbcr_enc``
176
177 - This information supplements the ``colorspace`` and must be set by
178 the driver for capture streams and by the application for output
179 streams, see :ref:`colorspaces`.
180
181 - .. row 13
182
183 - enum :c:type:`v4l2_quantization`
184
185 - ``quantization``
186
187 - This information supplements the ``colorspace`` and must be set by
188 the driver for capture streams and by the application for output
189 streams, see :ref:`colorspaces`.
190
191 - .. row 14
192
193 - enum :c:type:`v4l2_xfer_func`
194
195 - ``xfer_func``
196
197 - This information supplements the ``colorspace`` and must be set by
198 the driver for capture streams and by the application for output
199 streams, see :ref:`colorspaces`.
This page took 0.036273 seconds and 5 git commands to generate.