Mauro Carvalho Chehab | 8e080c2 | 2009-09-13 22:16:04 -0300 | [diff] [blame] | 1 | <title>Image Formats</title> |
| 2 | |
| 3 | <para>The V4L2 API was primarily designed for devices exchanging |
| 4 | image data with applications. The |
Pawel Osciak | 53b5d57 | 2011-01-07 01:41:33 -0300 | [diff] [blame] | 5 | <structname>v4l2_pix_format</structname> and <structname>v4l2_pix_format_mplane |
| 6 | </structname> structures define the format and layout of an image in memory. |
| 7 | The former is used with the single-planar API, while the latter is used with the |
| 8 | multi-planar version (see <xref linkend="planar-apis"/>). Image formats are |
| 9 | negotiated with the &VIDIOC-S-FMT; ioctl. (The explanations here focus on video |
Mauro Carvalho Chehab | 8e080c2 | 2009-09-13 22:16:04 -0300 | [diff] [blame] | 10 | capturing and output, for overlay frame buffer formats see also |
| 11 | &VIDIOC-G-FBUF;.)</para> |
| 12 | |
Pawel Osciak | 53b5d57 | 2011-01-07 01:41:33 -0300 | [diff] [blame] | 13 | <section> |
| 14 | <title>Single-planar format structure</title> |
Mauro Carvalho Chehab | 8e080c2 | 2009-09-13 22:16:04 -0300 | [diff] [blame] | 15 | <table pgwide="1" frame="none" id="v4l2-pix-format"> |
| 16 | <title>struct <structname>v4l2_pix_format</structname></title> |
| 17 | <tgroup cols="3"> |
| 18 | &cs-str; |
| 19 | <tbody valign="top"> |
| 20 | <row> |
| 21 | <entry>__u32</entry> |
| 22 | <entry><structfield>width</structfield></entry> |
| 23 | <entry>Image width in pixels.</entry> |
| 24 | </row> |
| 25 | <row> |
| 26 | <entry>__u32</entry> |
| 27 | <entry><structfield>height</structfield></entry> |
| 28 | <entry>Image height in pixels.</entry> |
| 29 | </row> |
| 30 | <row> |
| 31 | <entry spanname="hspan">Applications set these fields to |
| 32 | request an image size, drivers return the closest possible values. In |
| 33 | case of planar formats the <structfield>width</structfield> and |
| 34 | <structfield>height</structfield> applies to the largest plane. To |
| 35 | avoid ambiguities drivers must return values rounded up to a multiple |
| 36 | of the scale factor of any smaller planes. For example when the image |
| 37 | format is YUV 4:2:0, <structfield>width</structfield> and |
| 38 | <structfield>height</structfield> must be multiples of two.</entry> |
| 39 | </row> |
| 40 | <row> |
| 41 | <entry>__u32</entry> |
| 42 | <entry><structfield>pixelformat</structfield></entry> |
| 43 | <entry>The pixel format or type of compression, set by the |
| 44 | application. This is a little endian <link |
| 45 | linkend="v4l2-fourcc">four character code</link>. V4L2 defines |
| 46 | standard RGB formats in <xref linkend="rgb-formats" />, YUV formats in <xref |
| 47 | linkend="yuv-formats" />, and reserved codes in <xref |
| 48 | linkend="reserved-formats" /></entry> |
| 49 | </row> |
| 50 | <row> |
| 51 | <entry>&v4l2-field;</entry> |
| 52 | <entry><structfield>field</structfield></entry> |
| 53 | <entry>Video images are typically interlaced. Applications |
| 54 | can request to capture or output only the top or bottom field, or both |
| 55 | fields interlaced or sequentially stored in one buffer or alternating |
| 56 | in separate buffers. Drivers return the actual field order selected. |
| 57 | For details see <xref linkend="field-order" />.</entry> |
| 58 | </row> |
| 59 | <row> |
| 60 | <entry>__u32</entry> |
| 61 | <entry><structfield>bytesperline</structfield></entry> |
| 62 | <entry>Distance in bytes between the leftmost pixels in two |
| 63 | adjacent lines.</entry> |
| 64 | </row> |
| 65 | <row> |
| 66 | <entry spanname="hspan"><para>Both applications and drivers |
| 67 | can set this field to request padding bytes at the end of each line. |
| 68 | Drivers however may ignore the value requested by the application, |
| 69 | returning <structfield>width</structfield> times bytes per pixel or a |
| 70 | larger value required by the hardware. That implies applications can |
| 71 | just set this field to zero to get a reasonable |
| 72 | default.</para><para>Video hardware may access padding bytes, |
| 73 | therefore they must reside in accessible memory. Consider cases where |
| 74 | padding bytes after the last line of an image cross a system page |
| 75 | boundary. Input devices may write padding bytes, the value is |
| 76 | undefined. Output devices ignore the contents of padding |
| 77 | bytes.</para><para>When the image format is planar the |
| 78 | <structfield>bytesperline</structfield> value applies to the largest |
| 79 | plane and is divided by the same factor as the |
| 80 | <structfield>width</structfield> field for any smaller planes. For |
| 81 | example the Cb and Cr planes of a YUV 4:2:0 image have half as many |
| 82 | padding bytes following each line as the Y plane. To avoid ambiguities |
| 83 | drivers must return a <structfield>bytesperline</structfield> value |
| 84 | rounded up to a multiple of the scale factor.</para></entry> |
| 85 | </row> |
| 86 | <row> |
| 87 | <entry>__u32</entry> |
| 88 | <entry><structfield>sizeimage</structfield></entry> |
| 89 | <entry>Size in bytes of the buffer to hold a complete image, |
| 90 | set by the driver. Usually this is |
| 91 | <structfield>bytesperline</structfield> times |
| 92 | <structfield>height</structfield>. When the image consists of variable |
| 93 | length compressed data this is the maximum number of bytes required to |
| 94 | hold an image.</entry> |
| 95 | </row> |
| 96 | <row> |
| 97 | <entry>&v4l2-colorspace;</entry> |
| 98 | <entry><structfield>colorspace</structfield></entry> |
| 99 | <entry>This information supplements the |
| 100 | <structfield>pixelformat</structfield> and must be set by the driver, |
| 101 | see <xref linkend="colorspaces" />.</entry> |
| 102 | </row> |
| 103 | <row> |
| 104 | <entry>__u32</entry> |
| 105 | <entry><structfield>priv</structfield></entry> |
| 106 | <entry>Reserved for custom (driver defined) additional |
| 107 | information about formats. When not used drivers and applications must |
| 108 | set this field to zero.</entry> |
| 109 | </row> |
| 110 | </tbody> |
| 111 | </tgroup> |
| 112 | </table> |
Pawel Osciak | 53b5d57 | 2011-01-07 01:41:33 -0300 | [diff] [blame] | 113 | </section> |
| 114 | |
| 115 | <section> |
| 116 | <title>Multi-planar format structures</title> |
| 117 | <para>The <structname>v4l2_plane_pix_format</structname> structures define |
| 118 | size and layout for each of the planes in a multi-planar format. |
| 119 | The <structname>v4l2_pix_format_mplane</structname> structure contains |
| 120 | information common to all planes (such as image width and height) and |
| 121 | an array of <structname>v4l2_plane_pix_format</structname> structures, |
| 122 | describing all planes of that format.</para> |
| 123 | <table pgwide="1" frame="none" id="v4l2-plane-pix-format"> |
| 124 | <title>struct <structname>vl42_plane_pix_format</structname></title> |
| 125 | <tgroup cols="3"> |
| 126 | &cs-str; |
| 127 | <tbody valign="top"> |
| 128 | <row> |
| 129 | <entry>__u32</entry> |
| 130 | <entry><structfield>sizeimage</structfield></entry> |
| 131 | <entry>Maximum size in bytes required for image data in this plane. |
| 132 | </entry> |
| 133 | </row> |
| 134 | <row> |
| 135 | <entry>__u16</entry> |
| 136 | <entry><structfield>bytesperline</structfield></entry> |
| 137 | <entry>Distance in bytes between the leftmost pixels in two adjacent |
| 138 | lines.</entry> |
| 139 | </row> |
| 140 | <row> |
| 141 | <entry>__u16</entry> |
| 142 | <entry><structfield>reserved[7]</structfield></entry> |
| 143 | <entry>Reserved for future extensions. Should be zeroed by the |
| 144 | application.</entry> |
| 145 | </row> |
| 146 | </tbody> |
| 147 | </tgroup> |
| 148 | </table> |
| 149 | <table pgwide="1" frame="none" id="v4l2-pix-format-mplane"> |
| 150 | <title>struct <structname>v4l2_pix_format_mplane</structname></title> |
| 151 | <tgroup cols="3"> |
| 152 | &cs-str; |
| 153 | <tbody valign="top"> |
| 154 | <row> |
| 155 | <entry>__u32</entry> |
| 156 | <entry><structfield>width</structfield></entry> |
| 157 | <entry>Image width in pixels.</entry> |
| 158 | </row> |
| 159 | <row> |
| 160 | <entry>__u32</entry> |
| 161 | <entry><structfield>height</structfield></entry> |
| 162 | <entry>Image height in pixels.</entry> |
| 163 | </row> |
| 164 | <row> |
| 165 | <entry>__u32</entry> |
| 166 | <entry><structfield>pixelformat</structfield></entry> |
| 167 | <entry>The pixel format. Both single- and multi-planar four character |
| 168 | codes can be used.</entry> |
| 169 | </row> |
| 170 | <row> |
| 171 | <entry>&v4l2-field;</entry> |
| 172 | <entry><structfield>field</structfield></entry> |
| 173 | <entry>See &v4l2-pix-format;.</entry> |
| 174 | </row> |
| 175 | <row> |
| 176 | <entry>&v4l2-colorspace;</entry> |
| 177 | <entry><structfield>colorspace</structfield></entry> |
| 178 | <entry>See &v4l2-pix-format;.</entry> |
| 179 | </row> |
| 180 | <row> |
| 181 | <entry>&v4l2-plane-pix-format;</entry> |
| 182 | <entry><structfield>plane_fmt[VIDEO_MAX_PLANES]</structfield></entry> |
| 183 | <entry>An array of structures describing format of each plane this |
| 184 | pixel format consists of. The number of valid entries in this array |
| 185 | has to be put in the <structfield>num_planes</structfield> |
| 186 | field.</entry> |
| 187 | </row> |
| 188 | <row> |
| 189 | <entry>__u8</entry> |
| 190 | <entry><structfield>num_planes</structfield></entry> |
| 191 | <entry>Number of planes (i.e. separate memory buffers) for this format |
| 192 | and the number of valid entries in the |
| 193 | <structfield>plane_fmt</structfield> array.</entry> |
| 194 | </row> |
| 195 | <row> |
| 196 | <entry>__u8</entry> |
| 197 | <entry><structfield>reserved[11]</structfield></entry> |
| 198 | <entry>Reserved for future extensions. Should be zeroed by the |
| 199 | application.</entry> |
| 200 | </row> |
| 201 | </tbody> |
| 202 | </tgroup> |
| 203 | </table> |
| 204 | </section> |
Mauro Carvalho Chehab | 8e080c2 | 2009-09-13 22:16:04 -0300 | [diff] [blame] | 205 | |
| 206 | <section> |
| 207 | <title>Standard Image Formats</title> |
| 208 | |
| 209 | <para>In order to exchange images between drivers and |
| 210 | applications, it is necessary to have standard image data formats |
| 211 | which both sides will interpret the same way. V4L2 includes several |
| 212 | such formats, and this section is intended to be an unambiguous |
| 213 | specification of the standard image data formats in V4L2.</para> |
| 214 | |
| 215 | <para>V4L2 drivers are not limited to these formats, however. |
| 216 | Driver-specific formats are possible. In that case the application may |
| 217 | depend on a codec to convert images to one of the standard formats |
| 218 | when needed. But the data can still be stored and retrieved in the |
| 219 | proprietary format. For example, a device may support a proprietary |
| 220 | compressed format. Applications can still capture and save the data in |
| 221 | the compressed format, saving much disk space, and later use a codec |
| 222 | to convert the images to the X Windows screen format when the video is |
| 223 | to be displayed.</para> |
| 224 | |
| 225 | <para>Even so, ultimately, some standard formats are needed, so |
| 226 | the V4L2 specification would not be complete without well-defined |
| 227 | standard formats.</para> |
| 228 | |
| 229 | <para>The V4L2 standard formats are mainly uncompressed formats. The |
| 230 | pixels are always arranged in memory from left to right, and from top |
| 231 | to bottom. The first byte of data in the image buffer is always for |
| 232 | the leftmost pixel of the topmost row. Following that is the pixel |
| 233 | immediately to its right, and so on until the end of the top row of |
| 234 | pixels. Following the rightmost pixel of the row there may be zero or |
| 235 | more bytes of padding to guarantee that each row of pixel data has a |
| 236 | certain alignment. Following the pad bytes, if any, is data for the |
| 237 | leftmost pixel of the second row from the top, and so on. The last row |
| 238 | has just as many pad bytes after it as the other rows.</para> |
| 239 | |
| 240 | <para>In V4L2 each format has an identifier which looks like |
Pawel Osciak | 53b5d57 | 2011-01-07 01:41:33 -0300 | [diff] [blame] | 241 | <constant>PIX_FMT_XXX</constant>, defined in the <link |
| 242 | linkend="videodev">videodev.h</link> header file. These identifiers |
| 243 | represent <link linkend="v4l2-fourcc">four character (FourCC) codes</link> |
Mauro Carvalho Chehab | 8e080c2 | 2009-09-13 22:16:04 -0300 | [diff] [blame] | 244 | which are also listed below, however they are not the same as those |
| 245 | used in the Windows world.</para> |
Pawel Osciak | 53b5d57 | 2011-01-07 01:41:33 -0300 | [diff] [blame] | 246 | |
| 247 | <para>For some formats, data is stored in separate, discontiguous |
| 248 | memory buffers. Those formats are identified by a separate set of FourCC codes |
| 249 | and are referred to as "multi-planar formats". For example, a YUV422 frame is |
| 250 | normally stored in one memory buffer, but it can also be placed in two or three |
| 251 | separate buffers, with Y component in one buffer and CbCr components in another |
| 252 | in the 2-planar version or with each component in its own buffer in the |
| 253 | 3-planar case. Those sub-buffers are referred to as "planes".</para> |
Mauro Carvalho Chehab | 8e080c2 | 2009-09-13 22:16:04 -0300 | [diff] [blame] | 254 | </section> |
| 255 | |
| 256 | <section id="colorspaces"> |
| 257 | <title>Colorspaces</title> |
| 258 | |
| 259 | <para>[intro]</para> |
| 260 | |
| 261 | <!-- See proposal by Billy Biggs, video4linux-list@redhat.com |
| 262 | on 11 Oct 2002, subject: "Re: [V4L] Re: v4l2 api", and |
| 263 | http://vektor.theorem.ca/graphics/ycbcr/ and |
Mauro Carvalho Chehab | e5b20214 | 2009-09-15 20:49:43 -0300 | [diff] [blame] | 264 | http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html --> |
Mauro Carvalho Chehab | 8e080c2 | 2009-09-13 22:16:04 -0300 | [diff] [blame] | 265 | |
| 266 | <para> |
| 267 | <variablelist> |
| 268 | <varlistentry> |
| 269 | <term>Gamma Correction</term> |
| 270 | <listitem> |
| 271 | <para>[to do]</para> |
| 272 | <para>E'<subscript>R</subscript> = f(R)</para> |
| 273 | <para>E'<subscript>G</subscript> = f(G)</para> |
| 274 | <para>E'<subscript>B</subscript> = f(B)</para> |
| 275 | </listitem> |
| 276 | </varlistentry> |
| 277 | <varlistentry> |
| 278 | <term>Construction of luminance and color-difference |
| 279 | signals</term> |
| 280 | <listitem> |
| 281 | <para>[to do]</para> |
| 282 | <para>E'<subscript>Y</subscript> = |
| 283 | Coeff<subscript>R</subscript> E'<subscript>R</subscript> |
| 284 | + Coeff<subscript>G</subscript> E'<subscript>G</subscript> |
| 285 | + Coeff<subscript>B</subscript> E'<subscript>B</subscript></para> |
| 286 | <para>(E'<subscript>R</subscript> - E'<subscript>Y</subscript>) = E'<subscript>R</subscript> |
| 287 | - Coeff<subscript>R</subscript> E'<subscript>R</subscript> |
| 288 | - Coeff<subscript>G</subscript> E'<subscript>G</subscript> |
| 289 | - Coeff<subscript>B</subscript> E'<subscript>B</subscript></para> |
| 290 | <para>(E'<subscript>B</subscript> - E'<subscript>Y</subscript>) = E'<subscript>B</subscript> |
| 291 | - Coeff<subscript>R</subscript> E'<subscript>R</subscript> |
| 292 | - Coeff<subscript>G</subscript> E'<subscript>G</subscript> |
| 293 | - Coeff<subscript>B</subscript> E'<subscript>B</subscript></para> |
| 294 | </listitem> |
| 295 | </varlistentry> |
| 296 | <varlistentry> |
| 297 | <term>Re-normalized color-difference signals</term> |
| 298 | <listitem> |
| 299 | <para>The color-difference signals are scaled back to unity |
| 300 | range [-0.5;+0.5]:</para> |
| 301 | <para>K<subscript>B</subscript> = 0.5 / (1 - Coeff<subscript>B</subscript>)</para> |
| 302 | <para>K<subscript>R</subscript> = 0.5 / (1 - Coeff<subscript>R</subscript>)</para> |
| 303 | <para>P<subscript>B</subscript> = |
| 304 | K<subscript>B</subscript> (E'<subscript>B</subscript> - E'<subscript>Y</subscript>) = |
| 305 | 0.5 (Coeff<subscript>R</subscript> / Coeff<subscript>B</subscript>) E'<subscript>R</subscript> |
| 306 | + 0.5 (Coeff<subscript>G</subscript> / Coeff<subscript>B</subscript>) E'<subscript>G</subscript> |
| 307 | + 0.5 E'<subscript>B</subscript></para> |
| 308 | <para>P<subscript>R</subscript> = |
| 309 | K<subscript>R</subscript> (E'<subscript>R</subscript> - E'<subscript>Y</subscript>) = |
| 310 | 0.5 E'<subscript>R</subscript> |
| 311 | + 0.5 (Coeff<subscript>G</subscript> / Coeff<subscript>R</subscript>) E'<subscript>G</subscript> |
| 312 | + 0.5 (Coeff<subscript>B</subscript> / Coeff<subscript>R</subscript>) E'<subscript>B</subscript></para> |
| 313 | </listitem> |
| 314 | </varlistentry> |
| 315 | <varlistentry> |
| 316 | <term>Quantization</term> |
| 317 | <listitem> |
| 318 | <para>[to do]</para> |
| 319 | <para>Y' = (Lum. Levels - 1) · E'<subscript>Y</subscript> + Lum. Offset</para> |
| 320 | <para>C<subscript>B</subscript> = (Chrom. Levels - 1) |
| 321 | · P<subscript>B</subscript> + Chrom. Offset</para> |
| 322 | <para>C<subscript>R</subscript> = (Chrom. Levels - 1) |
| 323 | · P<subscript>R</subscript> + Chrom. Offset</para> |
| 324 | <para>Rounding to the nearest integer and clamping to the range |
| 325 | [0;255] finally yields the digital color components Y'CbCr |
| 326 | stored in YUV images.</para> |
| 327 | </listitem> |
| 328 | </varlistentry> |
| 329 | </variablelist> |
| 330 | </para> |
| 331 | |
| 332 | <example> |
| 333 | <title>ITU-R Rec. BT.601 color conversion</title> |
| 334 | |
| 335 | <para>Forward Transformation</para> |
| 336 | |
| 337 | <programlisting> |
| 338 | int ER, EG, EB; /* gamma corrected RGB input [0;255] */ |
| 339 | int Y1, Cb, Cr; /* output [0;255] */ |
| 340 | |
| 341 | double r, g, b; /* temporaries */ |
| 342 | double y1, pb, pr; |
| 343 | |
| 344 | int |
| 345 | clamp (double x) |
| 346 | { |
| 347 | int r = x; /* round to nearest */ |
| 348 | |
| 349 | if (r < 0) return 0; |
| 350 | else if (r > 255) return 255; |
| 351 | else return r; |
| 352 | } |
| 353 | |
| 354 | r = ER / 255.0; |
| 355 | g = EG / 255.0; |
| 356 | b = EB / 255.0; |
| 357 | |
| 358 | y1 = 0.299 * r + 0.587 * g + 0.114 * b; |
| 359 | pb = -0.169 * r - 0.331 * g + 0.5 * b; |
| 360 | pr = 0.5 * r - 0.419 * g - 0.081 * b; |
| 361 | |
| 362 | Y1 = clamp (219 * y1 + 16); |
| 363 | Cb = clamp (224 * pb + 128); |
| 364 | Cr = clamp (224 * pr + 128); |
| 365 | |
| 366 | /* or shorter */ |
| 367 | |
| 368 | y1 = 0.299 * ER + 0.587 * EG + 0.114 * EB; |
| 369 | |
| 370 | Y1 = clamp ( (219 / 255.0) * y1 + 16); |
| 371 | Cb = clamp (((224 / 255.0) / (2 - 2 * 0.114)) * (EB - y1) + 128); |
| 372 | Cr = clamp (((224 / 255.0) / (2 - 2 * 0.299)) * (ER - y1) + 128); |
| 373 | </programlisting> |
| 374 | |
| 375 | <para>Inverse Transformation</para> |
| 376 | |
| 377 | <programlisting> |
| 378 | int Y1, Cb, Cr; /* gamma pre-corrected input [0;255] */ |
| 379 | int ER, EG, EB; /* output [0;255] */ |
| 380 | |
| 381 | double r, g, b; /* temporaries */ |
| 382 | double y1, pb, pr; |
| 383 | |
| 384 | int |
| 385 | clamp (double x) |
| 386 | { |
| 387 | int r = x; /* round to nearest */ |
| 388 | |
| 389 | if (r < 0) return 0; |
| 390 | else if (r > 255) return 255; |
| 391 | else return r; |
| 392 | } |
| 393 | |
| 394 | y1 = (255 / 219.0) * (Y1 - 16); |
| 395 | pb = (255 / 224.0) * (Cb - 128); |
| 396 | pr = (255 / 224.0) * (Cr - 128); |
| 397 | |
| 398 | r = 1.0 * y1 + 0 * pb + 1.402 * pr; |
| 399 | g = 1.0 * y1 - 0.344 * pb - 0.714 * pr; |
| 400 | b = 1.0 * y1 + 1.772 * pb + 0 * pr; |
| 401 | |
| 402 | ER = clamp (r * 255); /* [ok? one should prob. limit y1,pb,pr] */ |
| 403 | EG = clamp (g * 255); |
| 404 | EB = clamp (b * 255); |
| 405 | </programlisting> |
| 406 | </example> |
| 407 | |
| 408 | <table pgwide="1" id="v4l2-colorspace" orient="land"> |
| 409 | <title>enum v4l2_colorspace</title> |
| 410 | <tgroup cols="11" align="center"> |
| 411 | <colspec align="left" /> |
| 412 | <colspec align="center" /> |
| 413 | <colspec align="left" /> |
| 414 | <colspec colname="cr" /> |
| 415 | <colspec colname="cg" /> |
| 416 | <colspec colname="cb" /> |
| 417 | <colspec colname="wp" /> |
| 418 | <colspec colname="gc" /> |
| 419 | <colspec colname="lum" /> |
| 420 | <colspec colname="qy" /> |
| 421 | <colspec colname="qc" /> |
| 422 | <spanspec namest="cr" nameend="cb" spanname="chrom" /> |
| 423 | <spanspec namest="qy" nameend="qc" spanname="quant" /> |
| 424 | <spanspec namest="lum" nameend="qc" spanname="spam" /> |
| 425 | <thead> |
| 426 | <row> |
| 427 | <entry morerows="1">Identifier</entry> |
| 428 | <entry morerows="1">Value</entry> |
| 429 | <entry morerows="1">Description</entry> |
| 430 | <entry spanname="chrom">Chromaticities<footnote> |
| 431 | <para>The coordinates of the color primaries are |
| 432 | given in the CIE system (1931)</para> |
| 433 | </footnote></entry> |
| 434 | <entry morerows="1">White Point</entry> |
| 435 | <entry morerows="1">Gamma Correction</entry> |
| 436 | <entry morerows="1">Luminance E'<subscript>Y</subscript></entry> |
| 437 | <entry spanname="quant">Quantization</entry> |
| 438 | </row> |
| 439 | <row> |
| 440 | <entry>Red</entry> |
| 441 | <entry>Green</entry> |
| 442 | <entry>Blue</entry> |
| 443 | <entry>Y'</entry> |
| 444 | <entry>Cb, Cr</entry> |
| 445 | </row> |
| 446 | </thead> |
| 447 | <tbody valign="top"> |
| 448 | <row> |
| 449 | <entry><constant>V4L2_COLORSPACE_SMPTE170M</constant></entry> |
| 450 | <entry>1</entry> |
| 451 | <entry>NTSC/PAL according to <xref linkend="smpte170m" />, |
| 452 | <xref linkend="itu601" /></entry> |
| 453 | <entry>x = 0.630, y = 0.340</entry> |
| 454 | <entry>x = 0.310, y = 0.595</entry> |
| 455 | <entry>x = 0.155, y = 0.070</entry> |
| 456 | <entry>x = 0.3127, y = 0.3290, |
| 457 | Illuminant D<subscript>65</subscript></entry> |
| 458 | <entry>E' = 4.5 I for I ≤0.018, |
| 459 | 1.099 I<superscript>0.45</superscript> - 0.099 for 0.018 < I</entry> |
| 460 | <entry>0.299 E'<subscript>R</subscript> |
| 461 | + 0.587 E'<subscript>G</subscript> |
| 462 | + 0.114 E'<subscript>B</subscript></entry> |
| 463 | <entry>219 E'<subscript>Y</subscript> + 16</entry> |
| 464 | <entry>224 P<subscript>B,R</subscript> + 128</entry> |
| 465 | </row> |
| 466 | <row> |
| 467 | <entry><constant>V4L2_COLORSPACE_SMPTE240M</constant></entry> |
| 468 | <entry>2</entry> |
| 469 | <entry>1125-Line (US) HDTV, see <xref |
| 470 | linkend="smpte240m" /></entry> |
| 471 | <entry>x = 0.630, y = 0.340</entry> |
| 472 | <entry>x = 0.310, y = 0.595</entry> |
| 473 | <entry>x = 0.155, y = 0.070</entry> |
| 474 | <entry>x = 0.3127, y = 0.3290, |
| 475 | Illuminant D<subscript>65</subscript></entry> |
| 476 | <entry>E' = 4 I for I ≤0.0228, |
| 477 | 1.1115 I<superscript>0.45</superscript> - 0.1115 for 0.0228 < I</entry> |
| 478 | <entry>0.212 E'<subscript>R</subscript> |
| 479 | + 0.701 E'<subscript>G</subscript> |
| 480 | + 0.087 E'<subscript>B</subscript></entry> |
| 481 | <entry>219 E'<subscript>Y</subscript> + 16</entry> |
| 482 | <entry>224 P<subscript>B,R</subscript> + 128</entry> |
| 483 | </row> |
| 484 | <row> |
| 485 | <entry><constant>V4L2_COLORSPACE_REC709</constant></entry> |
| 486 | <entry>3</entry> |
| 487 | <entry>HDTV and modern devices, see <xref |
| 488 | linkend="itu709" /></entry> |
| 489 | <entry>x = 0.640, y = 0.330</entry> |
| 490 | <entry>x = 0.300, y = 0.600</entry> |
| 491 | <entry>x = 0.150, y = 0.060</entry> |
| 492 | <entry>x = 0.3127, y = 0.3290, |
| 493 | Illuminant D<subscript>65</subscript></entry> |
| 494 | <entry>E' = 4.5 I for I ≤0.018, |
| 495 | 1.099 I<superscript>0.45</superscript> - 0.099 for 0.018 < I</entry> |
| 496 | <entry>0.2125 E'<subscript>R</subscript> |
| 497 | + 0.7154 E'<subscript>G</subscript> |
| 498 | + 0.0721 E'<subscript>B</subscript></entry> |
| 499 | <entry>219 E'<subscript>Y</subscript> + 16</entry> |
| 500 | <entry>224 P<subscript>B,R</subscript> + 128</entry> |
| 501 | </row> |
| 502 | <row> |
| 503 | <entry><constant>V4L2_COLORSPACE_BT878</constant></entry> |
| 504 | <entry>4</entry> |
| 505 | <entry>Broken Bt878 extents<footnote> |
| 506 | <para>The ubiquitous Bt878 video capture chip |
| 507 | quantizes E'<subscript>Y</subscript> to 238 levels, yielding a range |
| 508 | of Y' = 16 … 253, unlike Rec. 601 Y' = 16 … |
| 509 | 235. This is not a typo in the Bt878 documentation, it has been |
| 510 | implemented in silicon. The chroma extents are unclear.</para> |
| 511 | </footnote>, <xref linkend="itu601" /></entry> |
| 512 | <entry>?</entry> |
| 513 | <entry>?</entry> |
| 514 | <entry>?</entry> |
| 515 | <entry>?</entry> |
| 516 | <entry>?</entry> |
| 517 | <entry>0.299 E'<subscript>R</subscript> |
| 518 | + 0.587 E'<subscript>G</subscript> |
| 519 | + 0.114 E'<subscript>B</subscript></entry> |
| 520 | <entry><emphasis>237</emphasis> E'<subscript>Y</subscript> + 16</entry> |
| 521 | <entry>224 P<subscript>B,R</subscript> + 128 (probably)</entry> |
| 522 | </row> |
| 523 | <row> |
| 524 | <entry><constant>V4L2_COLORSPACE_470_SYSTEM_M</constant></entry> |
| 525 | <entry>5</entry> |
| 526 | <entry>M/NTSC<footnote> |
| 527 | <para>No identifier exists for M/PAL which uses |
| 528 | the chromaticities of M/NTSC, the remaining parameters are equal to B and |
| 529 | G/PAL.</para> |
| 530 | </footnote> according to <xref linkend="itu470" />, <xref |
| 531 | linkend="itu601" /></entry> |
| 532 | <entry>x = 0.67, y = 0.33</entry> |
| 533 | <entry>x = 0.21, y = 0.71</entry> |
| 534 | <entry>x = 0.14, y = 0.08</entry> |
| 535 | <entry>x = 0.310, y = 0.316, Illuminant C</entry> |
| 536 | <entry>?</entry> |
| 537 | <entry>0.299 E'<subscript>R</subscript> |
| 538 | + 0.587 E'<subscript>G</subscript> |
| 539 | + 0.114 E'<subscript>B</subscript></entry> |
| 540 | <entry>219 E'<subscript>Y</subscript> + 16</entry> |
| 541 | <entry>224 P<subscript>B,R</subscript> + 128</entry> |
| 542 | </row> |
| 543 | <row> |
| 544 | <entry><constant>V4L2_COLORSPACE_470_SYSTEM_BG</constant></entry> |
| 545 | <entry>6</entry> |
| 546 | <entry>625-line PAL and SECAM systems according to <xref |
| 547 | linkend="itu470" />, <xref linkend="itu601" /></entry> |
| 548 | <entry>x = 0.64, y = 0.33</entry> |
| 549 | <entry>x = 0.29, y = 0.60</entry> |
| 550 | <entry>x = 0.15, y = 0.06</entry> |
| 551 | <entry>x = 0.313, y = 0.329, |
| 552 | Illuminant D<subscript>65</subscript></entry> |
| 553 | <entry>?</entry> |
| 554 | <entry>0.299 E'<subscript>R</subscript> |
| 555 | + 0.587 E'<subscript>G</subscript> |
| 556 | + 0.114 E'<subscript>B</subscript></entry> |
| 557 | <entry>219 E'<subscript>Y</subscript> + 16</entry> |
| 558 | <entry>224 P<subscript>B,R</subscript> + 128</entry> |
| 559 | </row> |
| 560 | <row> |
| 561 | <entry><constant>V4L2_COLORSPACE_JPEG</constant></entry> |
| 562 | <entry>7</entry> |
| 563 | <entry>JPEG Y'CbCr, see <xref linkend="jfif" />, <xref linkend="itu601" /></entry> |
| 564 | <entry>?</entry> |
| 565 | <entry>?</entry> |
| 566 | <entry>?</entry> |
| 567 | <entry>?</entry> |
| 568 | <entry>?</entry> |
| 569 | <entry>0.299 E'<subscript>R</subscript> |
| 570 | + 0.587 E'<subscript>G</subscript> |
| 571 | + 0.114 E'<subscript>B</subscript></entry> |
| 572 | <entry>256 E'<subscript>Y</subscript> + 16<footnote> |
| 573 | <para>Note JFIF quantizes |
| 574 | Y'P<subscript>B</subscript>P<subscript>R</subscript> in range [0;+1] and |
| 575 | [-0.5;+0.5] to <emphasis>257</emphasis> levels, however Y'CbCr signals |
| 576 | are still clamped to [0;255].</para> |
| 577 | </footnote></entry> |
| 578 | <entry>256 P<subscript>B,R</subscript> + 128</entry> |
| 579 | </row> |
| 580 | <row> |
| 581 | <entry><constant>V4L2_COLORSPACE_SRGB</constant></entry> |
| 582 | <entry>8</entry> |
| 583 | <entry>[?]</entry> |
| 584 | <entry>x = 0.640, y = 0.330</entry> |
| 585 | <entry>x = 0.300, y = 0.600</entry> |
| 586 | <entry>x = 0.150, y = 0.060</entry> |
| 587 | <entry>x = 0.3127, y = 0.3290, |
| 588 | Illuminant D<subscript>65</subscript></entry> |
| 589 | <entry>E' = 4.5 I for I ≤0.018, |
| 590 | 1.099 I<superscript>0.45</superscript> - 0.099 for 0.018 < I</entry> |
| 591 | <entry spanname="spam">n/a</entry> |
| 592 | </row> |
| 593 | </tbody> |
| 594 | </tgroup> |
| 595 | </table> |
| 596 | </section> |
| 597 | |
| 598 | <section id="pixfmt-indexed"> |
| 599 | <title>Indexed Format</title> |
| 600 | |
| 601 | <para>In this format each pixel is represented by an 8 bit index |
| 602 | into a 256 entry ARGB palette. It is intended for <link |
| 603 | linkend="osd">Video Output Overlays</link> only. There are no ioctls to |
| 604 | access the palette, this must be done with ioctls of the Linux framebuffer API.</para> |
| 605 | |
| 606 | <table pgwide="0" frame="none"> |
| 607 | <title>Indexed Image Format</title> |
| 608 | <tgroup cols="37" align="center"> |
| 609 | <colspec colname="id" align="left" /> |
| 610 | <colspec colname="fourcc" /> |
| 611 | <colspec colname="bit" /> |
| 612 | |
| 613 | <colspec colnum="4" colname="b07" align="center" /> |
| 614 | <colspec colnum="5" colname="b06" align="center" /> |
| 615 | <colspec colnum="6" colname="b05" align="center" /> |
| 616 | <colspec colnum="7" colname="b04" align="center" /> |
| 617 | <colspec colnum="8" colname="b03" align="center" /> |
| 618 | <colspec colnum="9" colname="b02" align="center" /> |
| 619 | <colspec colnum="10" colname="b01" align="center" /> |
| 620 | <colspec colnum="11" colname="b00" align="center" /> |
| 621 | |
| 622 | <spanspec namest="b07" nameend="b00" spanname="b0" /> |
| 623 | <spanspec namest="b17" nameend="b10" spanname="b1" /> |
| 624 | <spanspec namest="b27" nameend="b20" spanname="b2" /> |
| 625 | <spanspec namest="b37" nameend="b30" spanname="b3" /> |
| 626 | <thead> |
| 627 | <row> |
| 628 | <entry>Identifier</entry> |
| 629 | <entry>Code</entry> |
| 630 | <entry> </entry> |
| 631 | <entry spanname="b0">Byte 0</entry> |
| 632 | </row> |
| 633 | <row> |
| 634 | <entry> </entry> |
| 635 | <entry> </entry> |
| 636 | <entry>Bit</entry> |
| 637 | <entry>7</entry> |
| 638 | <entry>6</entry> |
| 639 | <entry>5</entry> |
| 640 | <entry>4</entry> |
| 641 | <entry>3</entry> |
| 642 | <entry>2</entry> |
| 643 | <entry>1</entry> |
| 644 | <entry>0</entry> |
| 645 | </row> |
| 646 | </thead> |
| 647 | <tbody valign="top"> |
| 648 | <row id="V4L2-PIX-FMT-PAL8"> |
| 649 | <entry><constant>V4L2_PIX_FMT_PAL8</constant></entry> |
| 650 | <entry>'PAL8'</entry> |
| 651 | <entry></entry> |
| 652 | <entry>i<subscript>7</subscript></entry> |
| 653 | <entry>i<subscript>6</subscript></entry> |
| 654 | <entry>i<subscript>5</subscript></entry> |
| 655 | <entry>i<subscript>4</subscript></entry> |
| 656 | <entry>i<subscript>3</subscript></entry> |
| 657 | <entry>i<subscript>2</subscript></entry> |
| 658 | <entry>i<subscript>1</subscript></entry> |
| 659 | <entry>i<subscript>0</subscript></entry> |
| 660 | </row> |
| 661 | </tbody> |
| 662 | </tgroup> |
| 663 | </table> |
| 664 | </section> |
| 665 | |
| 666 | <section id="pixfmt-rgb"> |
| 667 | <title>RGB Formats</title> |
| 668 | |
| 669 | &sub-packed-rgb; |
| 670 | &sub-sbggr8; |
| 671 | &sub-sgbrg8; |
| 672 | &sub-sgrbg8; |
Guennadi Liakhovetski | 039aa70 | 2010-02-25 14:33:27 -0300 | [diff] [blame] | 673 | &sub-srggb8; |
Mauro Carvalho Chehab | 8e080c2 | 2009-09-13 22:16:04 -0300 | [diff] [blame] | 674 | &sub-sbggr16; |
Guennadi Liakhovetski | 039aa70 | 2010-02-25 14:33:27 -0300 | [diff] [blame] | 675 | &sub-srggb10; |
Mauro Carvalho Chehab | 115d253 | 2011-05-25 11:55:57 -0300 | [diff] [blame] | 676 | &sub-srggb12; |
Mauro Carvalho Chehab | 8e080c2 | 2009-09-13 22:16:04 -0300 | [diff] [blame] | 677 | </section> |
| 678 | |
| 679 | <section id="yuv-formats"> |
| 680 | <title>YUV Formats</title> |
| 681 | |
| 682 | <para>YUV is the format native to TV broadcast and composite video |
| 683 | signals. It separates the brightness information (Y) from the color |
| 684 | information (U and V or Cb and Cr). The color information consists of |
| 685 | red and blue <emphasis>color difference</emphasis> signals, this way |
| 686 | the green component can be reconstructed by subtracting from the |
| 687 | brightness component. See <xref linkend="colorspaces" /> for conversion |
| 688 | examples. YUV was chosen because early television would only transmit |
| 689 | brightness information. To add color in a way compatible with existing |
| 690 | receivers a new signal carrier was added to transmit the color |
| 691 | difference signals. Secondary in the YUV format the U and V components |
| 692 | usually have lower resolution than the Y component. This is an analog |
| 693 | video compression technique taking advantage of a property of the |
| 694 | human visual system, being more sensitive to brightness |
| 695 | information.</para> |
| 696 | |
| 697 | &sub-packed-yuv; |
| 698 | &sub-grey; |
Guennadi Liakhovetski | 039aa70 | 2010-02-25 14:33:27 -0300 | [diff] [blame] | 699 | &sub-y10; |
Michael Jones | d924de0 | 2011-03-29 05:19:06 -0300 | [diff] [blame] | 700 | &sub-y12; |
Antonio Ospite | 8bb36c2 | 2011-04-07 12:45:51 -0300 | [diff] [blame] | 701 | &sub-y10b; |
Mauro Carvalho Chehab | 8e080c2 | 2009-09-13 22:16:04 -0300 | [diff] [blame] | 702 | &sub-y16; |
| 703 | &sub-yuyv; |
| 704 | &sub-uyvy; |
| 705 | &sub-yvyu; |
| 706 | &sub-vyuy; |
| 707 | &sub-y41p; |
| 708 | &sub-yuv420; |
Sylwester Nawrocki | 269da40 | 2011-01-09 09:01:10 -0300 | [diff] [blame] | 709 | &sub-yuv420m; |
Mauro Carvalho Chehab | 8e080c2 | 2009-09-13 22:16:04 -0300 | [diff] [blame] | 710 | &sub-yuv410; |
| 711 | &sub-yuv422p; |
| 712 | &sub-yuv411p; |
| 713 | &sub-nv12; |
Sylwester Nawrocki | 269da40 | 2011-01-09 09:01:10 -0300 | [diff] [blame] | 714 | &sub-nv12m; |
Kamil Debski | bd08a0c | 2011-03-11 06:16:22 -0300 | [diff] [blame] | 715 | &sub-nv12mt; |
Mauro Carvalho Chehab | 8e080c2 | 2009-09-13 22:16:04 -0300 | [diff] [blame] | 716 | &sub-nv16; |
Hans de Goede | 0e59fd0 | 2011-05-11 09:56:20 -0300 | [diff] [blame] | 717 | &sub-m420; |
Mauro Carvalho Chehab | 8e080c2 | 2009-09-13 22:16:04 -0300 | [diff] [blame] | 718 | </section> |
| 719 | |
| 720 | <section> |
| 721 | <title>Compressed Formats</title> |
| 722 | |
| 723 | <table pgwide="1" frame="none" id="compressed-formats"> |
| 724 | <title>Compressed Image Formats</title> |
| 725 | <tgroup cols="3" align="left"> |
| 726 | &cs-def; |
| 727 | <thead> |
| 728 | <row> |
| 729 | <entry>Identifier</entry> |
| 730 | <entry>Code</entry> |
| 731 | <entry>Details</entry> |
| 732 | </row> |
| 733 | </thead> |
| 734 | <tbody valign="top"> |
| 735 | <row id="V4L2-PIX-FMT-JPEG"> |
| 736 | <entry><constant>V4L2_PIX_FMT_JPEG</constant></entry> |
| 737 | <entry>'JPEG'</entry> |
| 738 | <entry>TBD. See also &VIDIOC-G-JPEGCOMP;, |
| 739 | &VIDIOC-S-JPEGCOMP;.</entry> |
| 740 | </row> |
| 741 | <row id="V4L2-PIX-FMT-MPEG"> |
| 742 | <entry><constant>V4L2_PIX_FMT_MPEG</constant></entry> |
| 743 | <entry>'MPEG'</entry> |
| 744 | <entry>MPEG stream. The actual format is determined by |
| 745 | extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see |
| 746 | <xref linkend="mpeg-control-id" />.</entry> |
| 747 | </row> |
| 748 | </tbody> |
| 749 | </tgroup> |
| 750 | </table> |
| 751 | </section> |
| 752 | |
| 753 | <section id="pixfmt-reserved"> |
| 754 | <title>Reserved Format Identifiers</title> |
| 755 | |
| 756 | <para>These formats are not defined by this specification, they |
| 757 | are just listed for reference and to avoid naming conflicts. If you |
| 758 | want to register your own format, send an e-mail to the linux-media mailing |
| 759 | list &v4l-ml; for inclusion in the <filename>videodev2.h</filename> |
| 760 | file. If you want to share your format with other developers add a |
| 761 | link to your documentation and send a copy to the linux-media mailing list |
| 762 | for inclusion in this section. If you think your format should be listed |
| 763 | in a standard format section please make a proposal on the linux-media mailing |
| 764 | list.</para> |
| 765 | |
| 766 | <table pgwide="1" frame="none" id="reserved-formats"> |
| 767 | <title>Reserved Image Formats</title> |
| 768 | <tgroup cols="3" align="left"> |
| 769 | &cs-def; |
| 770 | <thead> |
| 771 | <row> |
| 772 | <entry>Identifier</entry> |
| 773 | <entry>Code</entry> |
| 774 | <entry>Details</entry> |
| 775 | </row> |
| 776 | </thead> |
| 777 | <tbody valign="top"> |
| 778 | <row id="V4L2-PIX-FMT-DV"> |
| 779 | <entry><constant>V4L2_PIX_FMT_DV</constant></entry> |
| 780 | <entry>'dvsd'</entry> |
| 781 | <entry>unknown</entry> |
| 782 | </row> |
| 783 | <row id="V4L2-PIX-FMT-ET61X251"> |
| 784 | <entry><constant>V4L2_PIX_FMT_ET61X251</constant></entry> |
| 785 | <entry>'E625'</entry> |
| 786 | <entry>Compressed format of the ET61X251 driver.</entry> |
| 787 | </row> |
| 788 | <row id="V4L2-PIX-FMT-HI240"> |
| 789 | <entry><constant>V4L2_PIX_FMT_HI240</constant></entry> |
| 790 | <entry>'HI24'</entry> |
| 791 | <entry><para>8 bit RGB format used by the BTTV driver.</para></entry> |
| 792 | </row> |
| 793 | <row id="V4L2-PIX-FMT-HM12"> |
| 794 | <entry><constant>V4L2_PIX_FMT_HM12</constant></entry> |
| 795 | <entry>'HM12'</entry> |
| 796 | <entry><para>YUV 4:2:0 format used by the |
| 797 | IVTV driver, <ulink url="http://www.ivtvdriver.org/"> |
| 798 | http://www.ivtvdriver.org/</ulink></para><para>The format is documented in the |
| 799 | kernel sources in the file <filename>Documentation/video4linux/cx2341x/README.hm12</filename> |
| 800 | </para></entry> |
| 801 | </row> |
Mauro Carvalho Chehab | a99e3c5 | 2010-02-25 14:33:27 -0300 | [diff] [blame] | 802 | <row id="V4L2-PIX-FMT-CPIA1"> |
| 803 | <entry><constant>V4L2_PIX_FMT_CPIA1</constant></entry> |
| 804 | <entry>'CPIA'</entry> |
| 805 | <entry>YUV format used by the gspca cpia1 driver.</entry> |
| 806 | </row> |
Mauro Carvalho Chehab | 8e080c2 | 2009-09-13 22:16:04 -0300 | [diff] [blame] | 807 | <row id="V4L2-PIX-FMT-SPCA501"> |
| 808 | <entry><constant>V4L2_PIX_FMT_SPCA501</constant></entry> |
| 809 | <entry>'S501'</entry> |
| 810 | <entry>YUYV per line used by the gspca driver.</entry> |
| 811 | </row> |
| 812 | <row id="V4L2-PIX-FMT-SPCA505"> |
| 813 | <entry><constant>V4L2_PIX_FMT_SPCA505</constant></entry> |
| 814 | <entry>'S505'</entry> |
| 815 | <entry>YYUV per line used by the gspca driver.</entry> |
| 816 | </row> |
| 817 | <row id="V4L2-PIX-FMT-SPCA508"> |
| 818 | <entry><constant>V4L2_PIX_FMT_SPCA508</constant></entry> |
| 819 | <entry>'S508'</entry> |
| 820 | <entry>YUVY per line used by the gspca driver.</entry> |
| 821 | </row> |
| 822 | <row id="V4L2-PIX-FMT-SPCA561"> |
| 823 | <entry><constant>V4L2_PIX_FMT_SPCA561</constant></entry> |
| 824 | <entry>'S561'</entry> |
| 825 | <entry>Compressed GBRG Bayer format used by the gspca driver.</entry> |
| 826 | </row> |
Mauro Carvalho Chehab | 8e080c2 | 2009-09-13 22:16:04 -0300 | [diff] [blame] | 827 | <row id="V4L2-PIX-FMT-SGRBG10DPCM8"> |
| 828 | <entry><constant>V4L2_PIX_FMT_SGRBG10DPCM8</constant></entry> |
| 829 | <entry>'DB10'</entry> |
| 830 | <entry>10 bit raw Bayer DPCM compressed to 8 bits.</entry> |
| 831 | </row> |
| 832 | <row id="V4L2-PIX-FMT-PAC207"> |
| 833 | <entry><constant>V4L2_PIX_FMT_PAC207</constant></entry> |
| 834 | <entry>'P207'</entry> |
| 835 | <entry>Compressed BGGR Bayer format used by the gspca driver.</entry> |
| 836 | </row> |
| 837 | <row id="V4L2-PIX-FMT-MR97310A"> |
| 838 | <entry><constant>V4L2_PIX_FMT_MR97310A</constant></entry> |
| 839 | <entry>'M310'</entry> |
| 840 | <entry>Compressed BGGR Bayer format used by the gspca driver.</entry> |
| 841 | </row> |
| 842 | <row id="V4L2-PIX-FMT-OV511"> |
| 843 | <entry><constant>V4L2_PIX_FMT_OV511</constant></entry> |
| 844 | <entry>'O511'</entry> |
| 845 | <entry>OV511 JPEG format used by the gspca driver.</entry> |
| 846 | </row> |
| 847 | <row id="V4L2-PIX-FMT-OV518"> |
| 848 | <entry><constant>V4L2_PIX_FMT_OV518</constant></entry> |
| 849 | <entry>'O518'</entry> |
| 850 | <entry>OV518 JPEG format used by the gspca driver.</entry> |
| 851 | </row> |
| 852 | <row id="V4L2-PIX-FMT-PJPG"> |
| 853 | <entry><constant>V4L2_PIX_FMT_PJPG</constant></entry> |
| 854 | <entry>'PJPG'</entry> |
| 855 | <entry>Pixart 73xx JPEG format used by the gspca driver.</entry> |
| 856 | </row> |
| 857 | <row id="V4L2-PIX-FMT-SQ905C"> |
| 858 | <entry><constant>V4L2_PIX_FMT_SQ905C</constant></entry> |
| 859 | <entry>'905C'</entry> |
| 860 | <entry>Compressed RGGB bayer format used by the gspca driver.</entry> |
| 861 | </row> |
| 862 | <row id="V4L2-PIX-FMT-MJPEG"> |
| 863 | <entry><constant>V4L2_PIX_FMT_MJPEG</constant></entry> |
| 864 | <entry>'MJPG'</entry> |
| 865 | <entry>Compressed format used by the Zoran driver</entry> |
| 866 | </row> |
| 867 | <row id="V4L2-PIX-FMT-PWC1"> |
| 868 | <entry><constant>V4L2_PIX_FMT_PWC1</constant></entry> |
| 869 | <entry>'PWC1'</entry> |
| 870 | <entry>Compressed format of the PWC driver.</entry> |
| 871 | </row> |
| 872 | <row id="V4L2-PIX-FMT-PWC2"> |
| 873 | <entry><constant>V4L2_PIX_FMT_PWC2</constant></entry> |
| 874 | <entry>'PWC2'</entry> |
| 875 | <entry>Compressed format of the PWC driver.</entry> |
| 876 | </row> |
| 877 | <row id="V4L2-PIX-FMT-SN9C10X"> |
| 878 | <entry><constant>V4L2_PIX_FMT_SN9C10X</constant></entry> |
| 879 | <entry>'S910'</entry> |
| 880 | <entry>Compressed format of the SN9C102 driver.</entry> |
| 881 | </row> |
| 882 | <row id="V4L2-PIX-FMT-SN9C20X-I420"> |
| 883 | <entry><constant>V4L2_PIX_FMT_SN9C20X_I420</constant></entry> |
| 884 | <entry>'S920'</entry> |
| 885 | <entry>YUV 4:2:0 format of the gspca sn9c20x driver.</entry> |
| 886 | </row> |
Mauro Carvalho Chehab | a99e3c5 | 2010-02-25 14:33:27 -0300 | [diff] [blame] | 887 | <row id="V4L2-PIX-FMT-SN9C2028"> |
| 888 | <entry><constant>V4L2_PIX_FMT_SN9C2028</constant></entry> |
| 889 | <entry>'SONX'</entry> |
| 890 | <entry>Compressed GBRG bayer format of the gspca sn9c2028 driver.</entry> |
| 891 | </row> |
Hans Verkuil | 47a5030 | 2009-11-23 14:14:26 -0300 | [diff] [blame] | 892 | <row id="V4L2-PIX-FMT-STV0680"> |
| 893 | <entry><constant>V4L2_PIX_FMT_STV0680</constant></entry> |
| 894 | <entry>'S680'</entry> |
| 895 | <entry>Bayer format of the gspca stv0680 driver.</entry> |
| 896 | </row> |
Mauro Carvalho Chehab | 8e080c2 | 2009-09-13 22:16:04 -0300 | [diff] [blame] | 897 | <row id="V4L2-PIX-FMT-WNVA"> |
| 898 | <entry><constant>V4L2_PIX_FMT_WNVA</constant></entry> |
| 899 | <entry>'WNVA'</entry> |
| 900 | <entry><para>Used by the Winnov Videum driver, <ulink |
| 901 | url="http://www.thedirks.org/winnov/"> |
| 902 | http://www.thedirks.org/winnov/</ulink></para></entry> |
| 903 | </row> |
Mauro Carvalho Chehab | 4e5fee2 | 2009-09-16 23:56:44 -0300 | [diff] [blame] | 904 | <row id="V4L2-PIX-FMT-TM6000"> |
| 905 | <entry><constant>V4L2_PIX_FMT_TM6000</constant></entry> |
| 906 | <entry>'TM60'</entry> |
| 907 | <entry><para>Used by Trident tm6000</para></entry> |
| 908 | </row> |
Hans Verkuil | 5e765c6 | 2010-09-11 08:36:55 -0300 | [diff] [blame] | 909 | <row id="V4L2-PIX-FMT-CIT-YYVYUY"> |
Mauro Carvalho Chehab | 516c714 | 2010-09-06 14:05:43 -0300 | [diff] [blame] | 910 | <entry><constant>V4L2_PIX_FMT_CIT_YYVYUY</constant></entry> |
| 911 | <entry>'CITV'</entry> |
| 912 | <entry><para>Used by xirlink CIT, found at IBM webcams.</para> |
| 913 | <para>Uses one line of Y then 1 line of VYUY</para> |
| 914 | </entry> |
| 915 | </row> |
Hans Verkuil | 5e765c6 | 2010-09-11 08:36:55 -0300 | [diff] [blame] | 916 | <row id="V4L2-PIX-FMT-KONICA420"> |
Mauro Carvalho Chehab | 516c714 | 2010-09-06 14:05:43 -0300 | [diff] [blame] | 917 | <entry><constant>V4L2_PIX_FMT_KONICA420</constant></entry> |
| 918 | <entry>'KONI'</entry> |
| 919 | <entry><para>Used by Konica webcams.</para> |
| 920 | <para>YUV420 planar in blocks of 256 pixels.</para> |
| 921 | </entry> |
| 922 | </row> |
Mauro Carvalho Chehab | 8e080c2 | 2009-09-13 22:16:04 -0300 | [diff] [blame] | 923 | <row id="V4L2-PIX-FMT-YYUV"> |
| 924 | <entry><constant>V4L2_PIX_FMT_YYUV</constant></entry> |
| 925 | <entry>'YYUV'</entry> |
| 926 | <entry>unknown</entry> |
| 927 | </row> |
Hans Verkuil | b3e212dc | 2010-03-22 04:52:21 -0300 | [diff] [blame] | 928 | <row id="V4L2-PIX-FMT-Y4"> |
| 929 | <entry><constant>V4L2_PIX_FMT_Y4</constant></entry> |
| 930 | <entry>'Y04 '</entry> |
| 931 | <entry>Old 4-bit greyscale format. Only the least significant 4 bits of each byte are used, |
| 932 | the other bits are set to 0.</entry> |
| 933 | </row> |
| 934 | <row id="V4L2-PIX-FMT-Y6"> |
| 935 | <entry><constant>V4L2_PIX_FMT_Y6</constant></entry> |
| 936 | <entry>'Y06 '</entry> |
| 937 | <entry>Old 6-bit greyscale format. Only the least significant 6 bits of each byte are used, |
| 938 | the other bits are set to 0.</entry> |
| 939 | </row> |
Mauro Carvalho Chehab | 8e080c2 | 2009-09-13 22:16:04 -0300 | [diff] [blame] | 940 | </tbody> |
| 941 | </tgroup> |
| 942 | </table> |
| 943 | </section> |
| 944 | |
| 945 | <!-- |
| 946 | Local Variables: |
| 947 | mode: sgml |
| 948 | sgml-parent-document: "v4l2.sgml" |
| 949 | indent-tabs-mode: nil |
| 950 | End: |
| 951 | --> |