1<html><head><meta http-equiv="Content-Type" content="text/html; charset=ANSI_X3.4-1968"><title>Standard Image Formats</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"><link rel="home" href="index.html" title="LINUX MEDIA INFRASTRUCTURE API"><link rel="up" href="pixfmt.html" title="Chapter 2. Image Formats"><link rel="prev" href="ch02s02.html" title="Multi-planar format structures"><link rel="next" href="colorspaces.html" title="Colorspaces"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Standard Image Formats</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02s02.html">Prev</a> </td><th width="60%" align="center">Chapter 2. Image Formats</th><td width="20%" align="right"> <a accesskey="n" href="colorspaces.html">Next</a></td></tr></table><hr></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp1100448212"></a>Standard Image Formats</h2></div></div></div><p>In order to exchange images between drivers and 2applications, it is necessary to have standard image data formats 3which both sides will interpret the same way. V4L2 includes several 4such formats, and this section is intended to be an unambiguous 5specification of the standard image data formats in V4L2.</p><p>V4L2 drivers are not limited to these formats, however. 6Driver-specific formats are possible. In that case the application may 7depend on a codec to convert images to one of the standard formats 8when needed. But the data can still be stored and retrieved in the 9proprietary format. For example, a device may support a proprietary 10compressed format. Applications can still capture and save the data in 11the compressed format, saving much disk space, and later use a codec 12to convert the images to the X Windows screen format when the video is 13to be displayed.</p><p>Even so, ultimately, some standard formats are needed, so 14the V4L2 specification would not be complete without well-defined 15standard formats.</p><p>The V4L2 standard formats are mainly uncompressed formats. The 16pixels are always arranged in memory from left to right, and from top 17to bottom. The first byte of data in the image buffer is always for 18the leftmost pixel of the topmost row. Following that is the pixel 19immediately to its right, and so on until the end of the top row of 20pixels. Following the rightmost pixel of the row there may be zero or 21more bytes of padding to guarantee that each row of pixel data has a 22certain alignment. Following the pad bytes, if any, is data for the 23leftmost pixel of the second row from the top, and so on. The last row 24has just as many pad bytes after it as the other rows.</p><p>In V4L2 each format has an identifier which looks like 25<code class="constant">PIX_FMT_XXX</code>, defined in the <a class="link" href="videodev.html" title="Appendix C. Video For Linux Two Header File">videodev2.h</a> header file. These identifiers 26represent <a class="link" href="vidioc-enum-fmt.html#v4l2-fourcc">four character (FourCC) codes</a> 27which are also listed below, however they are not the same as those 28used in the Windows world.</p><p>For some formats, data is stored in separate, discontiguous 29memory buffers. Those formats are identified by a separate set of FourCC codes 30and are referred to as "multi-planar formats". For example, a YUV422 frame is 31normally stored in one memory buffer, but it can also be placed in two or three 32separate buffers, with Y component in one buffer and CbCr components in another 33in the 2-planar version or with each component in its own buffer in the 343-planar case. Those sub-buffers are referred to as "planes".</p></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch02s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="pixfmt.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="colorspaces.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Multi-planar format structures </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Colorspaces</td></tr></table></div></body></html> 35