diff options
author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-27 10:05:51 +0000 |
---|---|---|
committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-27 10:05:51 +0000 |
commit | 5d1646d90e1f2cceb9f0828f4b28318cd0ec7744 (patch) | |
tree | a94efe259b9009378be6d90eb30d2b019d95c194 /Documentation/userspace-api/media/v4l/pixfmt-intro.rst | |
parent | Initial commit. (diff) | |
download | linux-430c2fc249ea5c0536abd21c23382884005c9093.tar.xz linux-430c2fc249ea5c0536abd21c23382884005c9093.zip |
Adding upstream version 5.10.209.upstream/5.10.209upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'Documentation/userspace-api/media/v4l/pixfmt-intro.rst')
-rw-r--r-- | Documentation/userspace-api/media/v4l/pixfmt-intro.rst | 51 |
1 files changed, 51 insertions, 0 deletions
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-intro.rst b/Documentation/userspace-api/media/v4l/pixfmt-intro.rst new file mode 100644 index 000000000..14239ee82 --- /dev/null +++ b/Documentation/userspace-api/media/v4l/pixfmt-intro.rst @@ -0,0 +1,51 @@ +.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later + +********************** +Standard Image Formats +********************** + +In order to exchange images between drivers and applications, it is +necessary to have standard image data formats which both sides will +interpret the same way. V4L2 includes several such formats, and this +section is intended to be an unambiguous specification of the standard +image data formats in V4L2. + +V4L2 drivers are not limited to these formats, however. Driver-specific +formats are possible. In that case the application may depend on a codec +to convert images to one of the standard formats when needed. But the +data can still be stored and retrieved in the proprietary format. For +example, a device may support a proprietary compressed format. +Applications can still capture and save the data in the compressed +format, saving much disk space, and later use a codec to convert the +images to the X Windows screen format when the video is to be displayed. + +Even so, ultimately, some standard formats are needed, so the V4L2 +specification would not be complete without well-defined standard +formats. + +The V4L2 standard formats are mainly uncompressed formats. The pixels +are always arranged in memory from left to right, and from top to +bottom. The first byte of data in the image buffer is always for the +leftmost pixel of the topmost row. Following that is the pixel +immediately to its right, and so on until the end of the top row of +pixels. Following the rightmost pixel of the row there may be zero or +more bytes of padding to guarantee that each row of pixel data has a +certain alignment. Following the pad bytes, if any, is data for the +leftmost pixel of the second row from the top, and so on. The last row +has just as many pad bytes after it as the other rows. + +In V4L2 each format has an identifier which looks like ``PIX_FMT_XXX``, +defined in the :ref:`videodev2.h <videodev>` header file. These +identifiers represent +:ref:`four character (FourCC) codes <v4l2-fourcc>` which are also +listed below, however they are not the same as those used in the Windows +world. + +For some formats, data is stored in separate, discontiguous memory +buffers. Those formats are identified by a separate set of FourCC codes +and are referred to as "multi-planar formats". For example, a +:ref:`YUV422 <V4L2-PIX-FMT-YUV422M>` frame is normally stored in one +memory buffer, but it can also be placed in two or three separate +buffers, with Y component in one buffer and CbCr components in another +in the 2-planar version or with each component in its own buffer in the +3-planar case. Those sub-buffers are referred to as "*planes*". |