0001 .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
0002
0003 **********************
0004 Standard Image Formats
0005 **********************
0006
0007 In order to exchange images between drivers and applications, it is
0008 necessary to have standard image data formats which both sides will
0009 interpret the same way. V4L2 includes several such formats, and this
0010 section is intended to be an unambiguous specification of the standard
0011 image data formats in V4L2.
0012
0013 V4L2 drivers are not limited to these formats, however. Driver-specific
0014 formats are possible. In that case the application may depend on a codec
0015 to convert images to one of the standard formats when needed. But the
0016 data can still be stored and retrieved in the proprietary format. For
0017 example, a device may support a proprietary compressed format.
0018 Applications can still capture and save the data in the compressed
0019 format, saving much disk space, and later use a codec to convert the
0020 images to the X Windows screen format when the video is to be displayed.
0021
0022 Even so, ultimately, some standard formats are needed, so the V4L2
0023 specification would not be complete without well-defined standard
0024 formats.
0025
0026 The V4L2 standard formats are mainly uncompressed formats. The pixels
0027 are always arranged in memory from left to right, and from top to
0028 bottom. The first byte of data in the image buffer is always for the
0029 leftmost pixel of the topmost row. Following that is the pixel
0030 immediately to its right, and so on until the end of the top row of
0031 pixels. Following the rightmost pixel of the row there may be zero or
0032 more bytes of padding to guarantee that each row of pixel data has a
0033 certain alignment. Following the pad bytes, if any, is data for the
0034 leftmost pixel of the second row from the top, and so on. The last row
0035 has just as many pad bytes after it as the other rows.
0036
0037 In V4L2 each format has an identifier which looks like ``PIX_FMT_XXX``,
0038 defined in the :ref:`videodev2.h <videodev>` header file. These
0039 identifiers represent
0040 :ref:`four character (FourCC) codes <v4l2-fourcc>` which are also
0041 listed below, however they are not the same as those used in the Windows
0042 world.
0043
0044 For some formats, data is stored in separate, discontiguous memory
0045 buffers. Those formats are identified by a separate set of FourCC codes
0046 and are referred to as "multi-planar formats". For example, a
0047 :ref:`YUV422 <V4L2-PIX-FMT-YUV422M>` frame is normally stored in one
0048 memory buffer, but it can also be placed in two or three separate
0049 buffers, with Y component in one buffer and CbCr components in another
0050 in the 2-planar version or with each component in its own buffer in the
0051 3-planar case. Those sub-buffers are referred to as "*planes*".
