summaryrefslogtreecommitdiff
path: root/Documentation/userspace-api/media/v4l
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/userspace-api/media/v4l')
-rw-r--r--Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst13
-rw-r--r--Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst16
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-reserved.rst15
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-rgb.rst2
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst4
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst45
-rw-r--r--Documentation/userspace-api/media/v4l/v4l2grab.c.rst2
-rw-r--r--Documentation/userspace-api/media/v4l/vidioc-qbuf.rst2
8 files changed, 66 insertions, 33 deletions
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
index cc080c4257d0..6541e4c32b26 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
@@ -616,6 +616,12 @@ Stateless Codec Control ID
* - ``V4L2_H264_DECODE_PARAM_FLAG_BOTTOM_FIELD``
- 0x00000004
-
+ * - ``V4L2_H264_DECODE_PARAM_FLAG_PFRAME``
+ - 0x00000008
+ -
+ * - ``V4L2_H264_DECODE_PARAM_FLAG_BFRAME``
+ - 0x00000010
+ -
.. raw:: latex
@@ -1692,7 +1698,12 @@ See section '7.3.1 Tx mode semantics' of the :ref:`vp9` specification for more d
* - __u8
- ``reference_mode``
- Specifies the type of inter prediction to be used. See
- :ref:`Reference Mode<vp9_reference_mode>` for more details.
+ :ref:`Reference Mode<vp9_reference_mode>` for more details. Note that
+ this is derived as part of the compressed header parsing process and
+ for this reason should have been part of
+ :c:type: `v4l2_ctrl_vp9_compressed_hdr` optional control. It is safe to
+ set this value to zero if the driver does not require compressed
+ headers.
* - __u8
- ``reserved[7]``
- Applications and drivers must set this to zero.
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index e141f0e4eec9..4cd7c541fc30 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -3166,11 +3166,11 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
:c:func:`v4l2_timeval_to_ns()` function to convert the struct
:c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64.
* - __u8
- - ``rps``
- - The reference set for the reference frame
- (V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_BEFORE,
- V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_AFTER or
- V4L2_HEVC_DPB_ENTRY_RPS_LT_CURR)
+ - ``flags``
+ - Long term flag for the reference frame
+ (V4L2_HEVC_DPB_ENTRY_LONG_TERM_REFERENCE). The flag is set as
+ described in the ITU HEVC specification chapter "8.3.2 Decoding
+ process for reference picture set".
* - __u8
- ``field_pic``
- Whether the reference is a field picture or a frame.
@@ -3383,15 +3383,15 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
* - __u8
- ``poc_st_curr_before[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
- PocStCurrBefore as described in section 8.3.2 "Decoding process for reference
- picture set.
+ picture set": provides the index of the short term before references in DPB array.
* - __u8
- ``poc_st_curr_after[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
- PocStCurrAfter as described in section 8.3.2 "Decoding process for reference
- picture set.
+ picture set": provides the index of the short term after references in DPB array.
* - __u8
- ``poc_lt_curr[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
- PocLtCurr as described in section 8.3.2 "Decoding process for reference
- picture set.
+ picture set": provides the index of the long term references in DPB array.
* - __u64
- ``flags``
- See :ref:`Decode Parameters Flags <hevc_decode_params_flags>`
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst b/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst
index 2f2133b4cd9c..cabfa34b7db5 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst
@@ -233,19 +233,12 @@ please make a proposal on the linux-media mailing list.
- ``V4L2_PIX_FMT_MT21C``
- 'MT21'
- - Compressed two-planar YVU420 format used by Mediatek MT8173.
- The compression is lossless.
- It is an opaque intermediate format and the MDP hardware must be
+ - Compressed two-planar YVU420 format used by Mediatek MT8173, MT8192,
+ MT8195 and more. The compression is lossless. This format have
+ similitude with ``V4L2_PIX_FMT_MM21`` in term of alignment and tiling.
+ It remains an opaque intermediate format and the MDP hardware must be
used to convert ``V4L2_PIX_FMT_MT21C`` to ``V4L2_PIX_FMT_NV12M``,
``V4L2_PIX_FMT_YUV420M`` or ``V4L2_PIX_FMT_YVU420``.
- * .. _V4L2-PIX-FMT-MM21:
-
- - ``V4L2_PIX_FMT_MM21``
- - 'MM21'
- - Non-compressed, tiled two-planar format used by Mediatek MT8183.
- This is an opaque intermediate format and the MDP3 hardware can be
- used to convert it to other formats.
-
.. raw:: latex
\normalsize
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
index 48b0f787274c..30f51cd33f99 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
@@ -672,8 +672,8 @@ nomenclature that instead use the order of components as seen in a 24- or
- ``V4L2_PIX_FMT_BGR24``
- 'BGR3'
- - G\ :sub:`7-0`
- B\ :sub:`7-0`
+ - G\ :sub:`7-0`
- R\ :sub:`7-0`
-
* .. _V4L2-PIX-FMT-RGB24:
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst
index 91942c4f0967..8ebd58c3588f 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst
@@ -75,8 +75,8 @@ are often referred to as greyscale formats.
- ``V4L2_PIX_FMT_Y10P``
- 'Y10P'
- - Y'\ :sub:`0`\ [7:0]
- - Y'\ :sub:`1`\ [9:8]
+ - Y'\ :sub:`0`\ [9:2]
+ - Y'\ :sub:`1`\ [9:2]
- Y'\ :sub:`2`\ [9:2]
- Y'\ :sub:`3`\ [9:2]
- Y'\ :sub:`3`\ [1:0] Y'\ :sub:`2`\ [1:0] Y'\ :sub:`1`\ [1:0] Y'\ :sub:`0`\ [1:0]
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
index 3a09d93d405b..8dff5906639b 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
@@ -76,7 +76,7 @@ All components are stored with the same number of bits per component.
- 'NV21'
- 8
- 4:2:0
- - Cr, Cr
+ - Cr, Cb
- Yes
- Linear
* - V4L2_PIX_FMT_NV12M
@@ -90,7 +90,7 @@ All components are stored with the same number of bits per component.
- 'NM21'
- 8
- 4:2:0
- - Cr, Cr
+ - Cr, Cb
- No
- Linear
* - V4L2_PIX_FMT_NV12MT
@@ -120,7 +120,7 @@ All components are stored with the same number of bits per component.
- 'NV61'
- 8
- 4:2:2
- - Cr, Cr
+ - Cr, Cb
- Yes
- Linear
* - V4L2_PIX_FMT_NV16M
@@ -134,7 +134,7 @@ All components are stored with the same number of bits per component.
- 'NM61'
- 8
- 4:2:2
- - Cr, Cr
+ - Cr, Cb
- No
- Linear
* - V4L2_PIX_FMT_NV24
@@ -148,7 +148,7 @@ All components are stored with the same number of bits per component.
- 'NV42'
- 8
- 4:4:4
- - Cr, Cr
+ - Cr, Cb
- Yes
- Linear
@@ -257,6 +257,9 @@ of the luma plane.
.. _V4L2-PIX-FMT-NV12-4L4:
.. _V4L2-PIX-FMT-NV12-16L16:
.. _V4L2-PIX-FMT-NV12-32L32:
+.. _V4L2-PIX-FMT-NV12M-8L128:
+.. _V4L2-PIX-FMT-NV12M-10BE-8L128:
+.. _V4L2-PIX-FMT-MM21:
Tiled NV12
----------
@@ -281,21 +284,47 @@ If the vertical resolution is an odd number of tiles, the last row of
tiles is stored in linear order. The layouts of the luma and chroma
planes are identical.
-``V4L2_PIX_FMT_NV12_4L4`` stores pixel in 4x4 tiles, and stores
+``V4L2_PIX_FMT_NV12_4L4`` stores pixels in 4x4 tiles, and stores
tiles linearly in memory. The line stride and image height must be
aligned to a multiple of 4. The layouts of the luma and chroma planes are
identical.
-``V4L2_PIX_FMT_NV12_16L16`` stores pixel in 16x16 tiles, and stores
+``V4L2_PIX_FMT_NV12_16L16`` stores pixels in 16x16 tiles, and stores
tiles linearly in memory. The line stride and image height must be
aligned to a multiple of 16. The layouts of the luma and chroma planes are
identical.
-``V4L2_PIX_FMT_NV12_32L32`` stores pixel in 32x32 tiles, and stores
+``V4L2_PIX_FMT_NV12_32L32`` stores pixels in 32x32 tiles, and stores
tiles linearly in memory. The line stride and image height must be
aligned to a multiple of 32. The layouts of the luma and chroma planes are
identical.
+``V4L2_PIX_FMT_NV12M_8L128`` is similar to ``V4L2_PIX_FMT_NV12M`` but stores
+pixels in 2D 8x128 tiles, and stores tiles linearly in memory.
+The image height must be aligned to a multiple of 128.
+The layouts of the luma and chroma planes are identical.
+
+``V4L2_PIX_FMT_NV12M_10BE_8L128`` is similar to ``V4L2_PIX_FMT_NV12M`` but stores
+10 bits pixels in 2D 8x128 tiles, and stores tiles linearly in memory.
+the data is arranged in big endian order.
+The image height must be aligned to a multiple of 128.
+The layouts of the luma and chroma planes are identical.
+Note the tile size is 8bytes multiplied by 128 bytes,
+it means that the low bits and high bits of one pixel may be in different tiles.
+The 10 bit pixels are packed, so 5 bytes contain 4 10-bit pixels layout like
+this (for luma):
+byte 0: Y0(bits 9-2)
+byte 1: Y0(bits 1-0) Y1(bits 9-4)
+byte 2: Y1(bits 3-0) Y2(bits 9-6)
+byte 3: Y2(bits 5-0) Y3(bits 9-8)
+byte 4: Y3(bits 7-0)
+
+``V4L2_PIX_FMT_MM21`` store luma pixel in 16x32 tiles, and chroma pixels
+in 16x16 tiles. The line stride must be aligned to a multiple of 16 and the
+image height must be aligned to a multiple of 32. The number of luma and chroma
+tiles are identical, even though the tile size differ. The image is formed of
+two non-contiguous planes.
+
.. _nv12mt:
.. kernel-figure:: nv12mt.svg
diff --git a/Documentation/userspace-api/media/v4l/v4l2grab.c.rst b/Documentation/userspace-api/media/v4l/v4l2grab.c.rst
index b38f661da733..1a55e3617ea8 100644
--- a/Documentation/userspace-api/media/v4l/v4l2grab.c.rst
+++ b/Documentation/userspace-api/media/v4l/v4l2grab.c.rst
@@ -134,7 +134,7 @@ file: media/v4l/v4l2grab.c
tv.tv_usec = 0;
r = select(fd + 1, &fds, NULL, NULL, &tv);
- } while ((r == -1 && (errno = EINTR)));
+ } while ((r == -1 && (errno == EINTR)));
if (r == -1) {
perror("select");
return errno;
diff --git a/Documentation/userspace-api/media/v4l/vidioc-qbuf.rst b/Documentation/userspace-api/media/v4l/vidioc-qbuf.rst
index 77e0747a6d28..e4b3d9beb9ab 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-qbuf.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-qbuf.rst
@@ -125,7 +125,7 @@ Applications call the ``VIDIOC_DQBUF`` ioctl to dequeue a filled
queue. They just set the ``type``, ``memory`` and ``reserved`` fields of
a struct :c:type:`v4l2_buffer` as above, when
``VIDIOC_DQBUF`` is called with a pointer to this structure the driver
-fills the remaining fields or returns an error code. The driver may also
+fills all remaining fields or returns an error code. The driver may also
set ``V4L2_BUF_FLAG_ERROR`` in the ``flags`` field. It indicates a
non-critical (recoverable) streaming error. In such case the application
may continue as normal, but should be aware that data in the dequeued