52 lines · plain
1.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later2 3**********************4Standard Image Formats5**********************6 7In order to exchange images between drivers and applications, it is8necessary to have standard image data formats which both sides will9interpret the same way. V4L2 includes several such formats, and this10section is intended to be an unambiguous specification of the standard11image data formats in V4L2.12 13V4L2 drivers are not limited to these formats, however. Driver-specific14formats are possible. In that case the application may depend on a codec15to convert images to one of the standard formats when needed. But the16data can still be stored and retrieved in the proprietary format. For17example, a device may support a proprietary compressed format.18Applications can still capture and save the data in the compressed19format, saving much disk space, and later use a codec to convert the20images to the X Windows screen format when the video is to be displayed.21 22Even so, ultimately, some standard formats are needed, so the V4L223specification would not be complete without well-defined standard24formats.25 26The V4L2 standard formats are mainly uncompressed formats. The pixels27are always arranged in memory from left to right, and from top to28bottom. The first byte of data in the image buffer is always for the29leftmost pixel of the topmost row. Following that is the pixel30immediately to its right, and so on until the end of the top row of31pixels. Following the rightmost pixel of the row there may be zero or32more bytes of padding to guarantee that each row of pixel data has a33certain alignment. Following the pad bytes, if any, is data for the34leftmost pixel of the second row from the top, and so on. The last row35has just as many pad bytes after it as the other rows.36 37In V4L2 each format has an identifier which looks like ``PIX_FMT_XXX``,38defined in the :ref:`videodev2.h <videodev>` header file. These39identifiers represent40:ref:`four character (FourCC) codes <v4l2-fourcc>` which are also41listed below, however they are not the same as those used in the Windows42world.43 44For some formats, data is stored in separate, discontiguous memory45buffers. Those formats are identified by a separate set of FourCC codes46and are referred to as "multi-planar formats". For example, a47:ref:`YUV422 <V4L2-PIX-FMT-YUV422M>` frame is normally stored in one48memory buffer, but it can also be placed in two or three separate49buffers, with Y component in one buffer and CbCr components in another50in the 2-planar version or with each component in its own buffer in the513-planar case. Those sub-buffers are referred to as "*planes*".52