
For video capture it is the driver that reports the colorspace, transfer function, Y'CbCr/HSV encoding and quantization range used by the video, and there is no way to request something different, even though many HDTV receivers have some sort of colorspace conversion capabilities. For output video this feature already exists since the application specifies this information for the video format it will send out, and the transmitter will enable any available CSC if a format conversion has to be performed in order to match the capabilities of the sink. For video capture we propose adding new v4l2_pix_format flag: V4L2_PIX_FMT_FLAG_SET_CSC. The flag is set by the application, the driver will interpret the colorspace, xfer_func, ycbcr_enc/hsv_enc and quantization fields as the requested colorspace information and will attempt to do the conversion it supports. Drivers set the flags V4L2_FMT_FLAG_CSC_COLORSPACE, V4L2_FMT_FLAG_CSC_XFER_FUNC, V4L2_FMT_FLAG_CSC_YCBCR_ENC/V4L2_FMT_FLAG_CSC_HSV_ENC, V4L2_FMT_FLAG_CSC_QUANTIZATION, in the flags field of the struct v4l2_fmtdesc during enumeration to indicate that they support colorspace conversion for the respective field. Drivers do not have to actually look at the flags. If the flags are not set, then the fields 'colorspace', 'xfer_func', 'ycbcr_enc/hsv_enc', and 'quantization' are set to the default values by the core, i.e. just pass on the received format without conversion. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
124 lines
3.8 KiB
ReStructuredText
124 lines
3.8 KiB
ReStructuredText
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
|
|
|
******************************
|
|
Multi-planar format structures
|
|
******************************
|
|
|
|
The struct :c:type:`v4l2_plane_pix_format` structures define size
|
|
and layout for each of the planes in a multi-planar format. The
|
|
struct :c:type:`v4l2_pix_format_mplane` structure contains
|
|
information common to all planes (such as image width and height) and an
|
|
array of struct :c:type:`v4l2_plane_pix_format` structures,
|
|
describing all planes of that format.
|
|
|
|
|
|
|
|
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
|
|
|
|
.. c:type:: v4l2_plane_pix_format
|
|
|
|
.. flat-table:: struct v4l2_plane_pix_format
|
|
:header-rows: 0
|
|
:stub-columns: 0
|
|
:widths: 1 1 2
|
|
|
|
* - __u32
|
|
- ``sizeimage``
|
|
- Maximum size in bytes required for image data in this plane,
|
|
set by the driver. When the image consists of variable length
|
|
compressed data this is the number of bytes required by the
|
|
codec to support the worst-case compression scenario.
|
|
|
|
The driver will set the value for uncompressed images.
|
|
|
|
Clients are allowed to set the sizeimage field for variable length
|
|
compressed data flagged with ``V4L2_FMT_FLAG_COMPRESSED`` at
|
|
:ref:`VIDIOC_ENUM_FMT`, but the driver may ignore it and set the
|
|
value itself, or it may modify the provided value based on
|
|
alignment requirements or minimum/maximum size requirements.
|
|
If the client wants to leave this to the driver, then it should
|
|
set sizeimage to 0.
|
|
* - __u32
|
|
- ``bytesperline``
|
|
- Distance in bytes between the leftmost pixels in two adjacent
|
|
lines. See struct :c:type:`v4l2_pix_format`.
|
|
* - __u16
|
|
- ``reserved[6]``
|
|
- Reserved for future extensions. Should be zeroed by drivers and
|
|
applications.
|
|
|
|
|
|
.. raw:: latex
|
|
|
|
\small
|
|
|
|
.. tabularcolumns:: |p{4.4cm}|p{5.6cm}|p{7.5cm}|
|
|
|
|
.. c:type:: v4l2_pix_format_mplane
|
|
|
|
.. flat-table:: struct v4l2_pix_format_mplane
|
|
:header-rows: 0
|
|
:stub-columns: 0
|
|
:widths: 1 1 2
|
|
|
|
* - __u32
|
|
- ``width``
|
|
- Image width in pixels. See struct
|
|
:c:type:`v4l2_pix_format`.
|
|
* - __u32
|
|
- ``height``
|
|
- Image height in pixels. See struct
|
|
:c:type:`v4l2_pix_format`.
|
|
* - __u32
|
|
- ``pixelformat``
|
|
- The pixel format. Both single- and multi-planar four character
|
|
codes can be used.
|
|
* - __u32
|
|
- ``field``
|
|
- Field order, from enum :c:type:`v4l2_field`.
|
|
See struct :c:type:`v4l2_pix_format`.
|
|
* - __u32
|
|
- ``colorspace``
|
|
- Colorspace encoding, from enum :c:type:`v4l2_colorspace`.
|
|
See struct :c:type:`v4l2_pix_format`.
|
|
* - struct :c:type:`v4l2_plane_pix_format`
|
|
- ``plane_fmt[VIDEO_MAX_PLANES]``
|
|
- An array of structures describing format of each plane this pixel
|
|
format consists of. The number of valid entries in this array has
|
|
to be put in the ``num_planes`` field.
|
|
* - __u8
|
|
- ``num_planes``
|
|
- Number of planes (i.e. separate memory buffers) for this format
|
|
and the number of valid entries in the ``plane_fmt`` array.
|
|
* - __u8
|
|
- ``flags``
|
|
- Flags set by the application or driver, see :ref:`format-flags`.
|
|
* - union {
|
|
- (anonymous)
|
|
* - __u8
|
|
- ``ycbcr_enc``
|
|
- Y'CbCr encoding, from enum :c:type:`v4l2_ycbcr_encoding`.
|
|
See struct :c:type:`v4l2_pix_format`.
|
|
* - __u8
|
|
- ``hsv_enc``
|
|
- HSV encoding, from enum :c:type:`v4l2_hsv_encoding`.
|
|
See struct :c:type:`v4l2_pix_format`.
|
|
* - }
|
|
-
|
|
* - __u8
|
|
- ``quantization``
|
|
- Quantization range, from enum :c:type:`v4l2_quantization`.
|
|
See struct :c:type:`v4l2_pix_format`.
|
|
* - __u8
|
|
- ``xfer_func``
|
|
- Transfer function, from enum :c:type:`v4l2_xfer_func`.
|
|
See struct :c:type:`v4l2_pix_format`.
|
|
* - __u8
|
|
- ``reserved[7]``
|
|
- Reserved for future extensions. Should be zeroed by drivers and
|
|
applications.
|
|
|
|
.. raw:: latex
|
|
|
|
\normalsize
|