diff options
Diffstat (limited to 'Documentation/userspace-api/media/v4l')
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 |