struct v4l2_mbus_framefmt
&cs-str;
__u32widthImage width, in pixels.__u32heightImage height, in pixels.__u32codeFormat code, from &v4l2-mbus-pixelcode;.__u32fieldField order, from &v4l2-field;. See
for details.__u32colorspaceImage colorspace, from &v4l2-colorspace;. See
for details.__u32reserved[7]Reserved for future extensions. Applications and drivers must
set the array to zero.
Media Bus Pixel CodesThe media bus pixel codes describe image formats as flowing over
physical busses (both between separate physical components and inside SoC
devices). This should not be confused with the V4L2 pixel formats that
describe, using four character codes, image formats as stored in memory.
While there is a relationship between image formats on busses and
image formats in memory (a raw Bayer image won't be magically converted to
JPEG just by storing it to memory), there is no one-to-one correspondance
between them.Packed RGB FormatsThose formats transfer pixel data as red, green and blue components.
The format code is made of the following information.
The red, green and blue components order code, as encoded in a
pixel sample. Possible values are RGB and BGR.The number of bits per component, for each component. The values
can be different for all components. Common values are 555 and 565.The number of bus samples per pixel. Pixels that are wider than
the bus width must be transferred in multiple samples. Common values are
1 and 2.The bus width.For formats where the total number of bits per pixel is smaller
than the number of bus samples per pixel times the bus width, a padding
value stating if the bytes are padded in their most high order bits
(PADHI) or low order bits (PADLO).For formats where the number of bus samples per pixel is larger
than 1, an endianness value stating if the pixel is transferred MSB first
(BE) or LSB first (LE).For instance, a format where pixels are encoded as 5-bits red, 5-bits
green and 5-bit blue values padded on the high bit, transferred as 2 8-bit
samples per pixel with the most significant bits (padding, red and half of
the green value) transferred first will be named
V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE.
The following tables list existing packed RGB formats.
Bayer FormatsThose formats transfer pixel data as red, green and blue components.
The format code is made of the following information.
The red, green and blue components order code, as encoded in a
pixel sample. The possible values are shown in .The number of bits per pixel component. All components are
transferred on the same number of bits. Common values are 8, 10 and 12.The compression (optional). If the pixel components are
ALAW- or DPCM-compressed, a mention of the compression scheme and the
number of bits per compressed pixel component.The number of bus samples per pixel. Pixels that are wider than
the bus width must be transferred in multiple samples. Common values are
1 and 2.The bus width.For formats where the total number of bits per pixel is smaller
than the number of bus samples per pixel times the bus width, a padding
value stating if the bytes are padded in their most high order bits
(PADHI) or low order bits (PADLO).For formats where the number of bus samples per pixel is larger
than 1, an endianness value stating if the pixel is transferred MSB first
(BE) or LSB first (LE).For instance, a format with uncompressed 10-bit Bayer components
arranged in a red, green, green, blue pattern transferred as 2 8-bit
samples per pixel with the least significant bits transferred first will
be named V4L2_MBUS_FMT_SRGGB10_2X8_PADHI_LE.
The following table lists existing packed Bayer formats. The data
organization is given as an example for the first pixel only.
Packed YUV FormatsThose data formats transfer pixel data as (possibly downsampled) Y, U
and V components. Some formats include dummy bits in some of their samples
and are collectively referred to as "YDYC" (Y-Dummy-Y-Chroma) formats.
One cannot rely on the values of these dummy bits as those are undefined.
The format code is made of the following information.
The Y, U and V components order code, as transferred on the
bus. Possible values are YUYV, UYVY, YVYU and VYUY for formats with no
dummy bit, and YDYUYDYV, YDYVYDYU, YUYDYVYD and YVYDYUYD for YDYC formats.
The number of bits per pixel component. All components are
transferred on the same number of bits. Common values are 8, 10 and 12.The number of bus samples per pixel. Pixels that are wider than
the bus width must be transferred in multiple samples. Common values are
1, 1.5 (encoded as 1_5) and 2.The bus width. When the bus width is larger than the number of
bits per pixel component, several components are packed in a single bus
sample. The components are ordered as specified by the order code, with
components on the left of the code transferred in the high order bits.
Common values are 8 and 16.For instance, a format where pixels are encoded as 8-bit YUV values
downsampled to 4:2:2 and transferred as 2 8-bit bus samples per pixel in the
U, Y, V, Y order will be named V4L2_MBUS_FMT_UYVY8_2X8.
lists existing packed YUV
formats and describes the organization of each pixel data in each sample.
When a format pattern is split across multiple samples each of the samples
in the pattern is described.The role of each bit transferred over the bus is identified by one
of the following codes.yx for luma component bit number xux for blue chroma component bit number xvx for red chroma component bit number xax for alpha component bit number x- for non-available bits (for positions higher than the bus width)d for dummy bits
HSV/HSL FormatsThose formats transfer pixel data as RGB values in a cylindrical-coordinate
system using Hue-Saturation-Value or Hue-Saturation-Lightness components. The
format code is made of the following information.
The hue, saturation, value or lightness and optional alpha
components order code, as encoded in a pixel sample. The only currently
supported value is AHSV.
The number of bits per component, for each component. The values
can be different for all components. The only currently supported value is 8888.
The number of bus samples per pixel. Pixels that are wider than
the bus width must be transferred in multiple samples. The only currently
supported value is 1.The bus width.For formats where the total number of bits per pixel is smaller
than the number of bus samples per pixel times the bus width, a padding
value stating if the bytes are padded in their most high order bits
(PADHI) or low order bits (PADLO).For formats where the number of bus samples per pixel is larger
than 1, an endianness value stating if the pixel is transferred MSB first
(BE) or LSB first (LE).The following table lists existing HSV/HSL formats.
JPEG Compressed FormatsThose data formats consist of an ordered sequence of 8-bit bytes
obtained from JPEG compression process. Additionally to the
_JPEG postfix the format code is made of
the following information.
The number of bus samples per entropy encoded byte.The bus width.For instance, for a JPEG baseline process and an 8-bit bus width
the format will be named V4L2_MBUS_FMT_JPEG_1X8.
The following table lists existing JPEG compressed formats.
JPEG FormatsIdentifierCodeRemarksV4L2_MBUS_FMT_JPEG_1X80x4001Besides of its usage for the parallel bus this format is
recommended for transmission of JPEG data over MIPI CSI bus
using the User Defined 8-bit Data types.
Vendor and Device Specific FormatsExperimentalThis is an experimental
interface and may change in the future.This section lists complex data formats that are either vendor or
device specific.
The following table lists the existing vendor and device specific
formats.
Vendor and device specific formatsIdentifierCodeCommentsV4L2_MBUS_FMT_S5C_UYVY_JPEG_1X80x5001
Interleaved raw UYVY and JPEG image format with embedded
meta-data used by Samsung S3C73MX camera sensors.