Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
Source file repositories/reference/linux-study-clean/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst- Extension
.rst- Size
- 10687 bytes
- Lines
- 484
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: V4L
.. _packed-yuv:
******************
Packed YUV formats
******************
Similarly to the packed RGB formats, the packed YUV formats store the Y, Cb and
Cr components consecutively in memory. They may apply subsampling to the chroma
components and thus differ in how they interlave the three components.
.. note::
- In all the tables that follow, bit 7 is the most significant bit in a byte.
- 'Y', 'Cb' and 'Cr' denote bits of the luma, blue chroma (also known as
'U') and red chroma (also known as 'V') components respectively. 'A'
denotes bits of the alpha component (if supported by the format), and 'X'
denotes padding bits.
4:4:4 Subsampling
=================
These formats do not subsample the chroma components and store each pixels as a
full triplet of Y, Cb and Cr values.
The next table lists the packed YUV 4:4:4 formats with less than 8 bits per
component. They are named based on the order of the Y, Cb and Cr components as
seen in a 16-bit word, which is then stored in memory in little endian byte
order, and on the number of bits for each component. For instance the YUV565
format stores a pixel in a 16-bit word [15:0] laid out at as [Y'\ :sub:`4-0`
Cb\ :sub:`5-0` Cr\ :sub:`4-0`], and stored in memory in two bytes,
[Cb\ :sub:`2-0` Cr\ :sub:`4-0`] followed by [Y'\ :sub:`4-0` Cb\ :sub:`5-3`].
.. raw:: latex
\begingroup
\scriptsize
\setlength{\tabcolsep}{2pt}
.. tabularcolumns:: |p{3.5cm}|p{0.96cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|
.. flat-table:: Packed YUV 4:4:4 Image Formats (less than 8bpc)
:header-rows: 2
:stub-columns: 0
* - Identifier
- Code
- :cspan:`7` Byte 0 in memory
- :cspan:`7` Byte 1
* -
-
- 7
- 6
- 5
- 4
- 3
- 2
- 1
- 0
- 7
- 6
- 5
- 4
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.