linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ezequiel Garcia <ezequiel@collabora.com>
To: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Tomasz Figa <tfiga@chromium.org>,
	kernel@collabora.com, Jonas Karlman <jonas@kwiboo.se>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	Alexandre Courbot <acourbot@chromium.org>,
	Jeffrey Kardatzke <jkardatzke@chromium.org>,
	Nicolas Dufresne <nicolas.dufresne@collabora.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Maxime Ripard <mripard@kernel.org>,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	Ezequiel Garcia <ezequiel@collabora.com>
Subject: [PATCH v2 09/14] media: uapi: h264: Clarify SLICE_BASED mode
Date: Thu,  6 Aug 2020 12:13:05 -0300	[thread overview]
Message-ID: <20200806151310.98624-10-ezequiel@collabora.com> (raw)
In-Reply-To: <20200806151310.98624-1-ezequiel@collabora.com>

Currently, the SLICE_BASED and FRAME_BASED modes documentation
is misleading and not matching the intended use-cases.

Drop non-required fields SLICE_PARAMS 'start_byte_offset' and
DECODE_PARAMS 'num_slices' and clarify the decoding modes in the
documentation.

On SLICE_BASED mode, a single slice is expected per OUTPUT buffer,
and therefore 'start_byte_offset' is not needed (since the offset
to the slice is the start of the buffer).

This mode requires the use of CAPTURE buffer holding, and so
the number of slices shall not be required.

On FRAME_BASED mode, the devices are expected to take care of slice
parsing. Neither SLICE_PARAMS are required (and shouldn't be
exposed by frame-based drivers), nor the number of slices.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 .../media/v4l/ext-ctrls-codec.rst             | 39 +++++--------------
 include/media/h264-ctrls.h                    |  4 --
 2 files changed, 10 insertions(+), 33 deletions(-)

diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index fff74b7bf32a..b3963c1acc2c 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -1748,9 +1748,6 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
        This compound control is not yet part of the public kernel API
        and it is expected to change.
 
-       This structure is expected to be passed as an array, with one
-       entry for each slice included in the bitstream buffer.
-
 .. c:type:: v4l2_ctrl_h264_slice_params
 
 .. cssclass:: longtable
@@ -1760,17 +1757,9 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
     :stub-columns: 0
     :widths:       1 1 2
 
-    * - __u32
-      - ``start_byte_offset``
-        Offset (in bytes) from the beginning of the OUTPUT buffer to the start
-        of the slice. If the slice starts with a start code, then this is the
-        offset to such start code. When operating in slice-based decoding mode
-        (see :c:type:`v4l2_mpeg_video_h264_decode_mode`), this field should
-        be set to 0. When operating in frame-based decoding mode, this field
-        should be 0 for the first slice.
     * - __u32
       - ``header_bit_size``
-      -
+      - Offset in bits to slice_data() from the beginning of this slice.
     * - __u32
       - ``first_mb_in_slice``
       -
@@ -1998,12 +1987,6 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
     * - struct :c:type:`v4l2_h264_dpb_entry`
       - ``dpb[16]``
       -
-    * - __u16
-      - ``num_slices``
-      - Number of slices needed to decode the current frame/field. When
-        operating in slice-based decoding mode (see
-        :c:type:`v4l2_mpeg_video_h264_decode_mode`), this field
-        should always be set to one.
     * - __u16
       - ``nal_ref_idc``
       - NAL reference ID value coming from the NAL Unit header
@@ -2121,22 +2104,20 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
     * - ``V4L2_MPEG_VIDEO_H264_DECODE_MODE_SLICE_BASED``
       - 0
       - Decoding is done at the slice granularity.
-        In this mode, ``num_slices`` field in struct
-        :c:type:`v4l2_ctrl_h264_decode_params` should be set to 1,
-        and ``start_byte_offset`` in struct
-        :c:type:`v4l2_ctrl_h264_slice_params` should be set to 0.
         The OUTPUT buffer must contain a single slice.
+        When this mode is selected, the ``V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS``
+        control shall be set. When multiple slices compose a frame,
+        use of ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF`` flag
+        is required.
     * - ``V4L2_MPEG_VIDEO_H264_DECODE_MODE_FRAME_BASED``
       - 1
-      - Decoding is done at the frame granularity.
-        In this mode, ``num_slices`` field in struct
-        :c:type:`v4l2_ctrl_h264_decode_params` should be set to the number
-        of slices in the frame, and ``start_byte_offset`` in struct
-        :c:type:`v4l2_ctrl_h264_slice_params` should be set accordingly
-        for each slice. For the first slice, ``start_byte_offset`` should
-        be zero.
+      - Decoding is done at the frame granularity,
         The OUTPUT buffer must contain all slices needed to decode the
         frame. The OUTPUT buffer must also contain both fields.
+        This mode will be supported by devices that
+        parse the slice(s) header(s) in hardware. When this mode is
+        selected, the ``V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS``
+        control shall not be set.
 
 ``V4L2_CID_MPEG_VIDEO_H264_START_CODE (enum)``
     Specifies the H264 slice start code expected for each slice.
diff --git a/include/media/h264-ctrls.h b/include/media/h264-ctrls.h
index f74736fcfa00..ea8c8c93305b 100644
--- a/include/media/h264-ctrls.h
+++ b/include/media/h264-ctrls.h
@@ -158,9 +158,6 @@ struct v4l2_h264_reference {
 };
 
 struct v4l2_ctrl_h264_slice_params {
-	/* Offset in bytes to the start of slice in the OUTPUT buffer. */
-	__u32 start_byte_offset;
-
 	/* Offset in bits to slice_data() from the beginning of this slice. */
 	__u32 header_bit_size;
 
@@ -219,7 +216,6 @@ struct v4l2_h264_dpb_entry {
 
 struct v4l2_ctrl_h264_decode_params {
 	struct v4l2_h264_dpb_entry dpb[V4L2_H264_NUM_DPB_ENTRIES];
-	__u16 num_slices;
 	__u16 nal_ref_idc;
 	__s32 top_field_order_cnt;
 	__s32 bottom_field_order_cnt;
-- 
2.27.0


  parent reply	other threads:[~2020-08-06 17:36 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-06 15:12 [PATCH v2 00/14] Clean H264 stateless uAPI Ezequiel Garcia
2020-08-06 15:12 ` [PATCH v2 01/14] media: uapi: h264: Update reference lists Ezequiel Garcia
2020-08-06 15:47   ` Paul Kocialkowski
2020-08-06 15:54     ` Jernej Škrabec
2020-08-07 14:33     ` Ezequiel Garcia
2020-08-08 19:12   ` Ezequiel Garcia
2020-08-06 15:12 ` [PATCH v2 02/14] media: uapi: h264: Further clarify scaling lists order Ezequiel Garcia
2020-08-06 15:12 ` [PATCH v2 03/14] media: uapi: h264: Split prediction weight parameters Ezequiel Garcia
2020-08-08 21:01   ` Jonas Karlman
2020-08-09 13:55     ` Ezequiel Garcia
2020-08-09 21:11       ` Jernej Škrabec
2020-08-10 12:57         ` Ezequiel Garcia
2020-08-10 14:55           ` Jonas Karlman
2020-08-10 15:28             ` Ezequiel Garcia
2020-08-10 16:57               ` Jonas Karlman
2020-08-10 20:04                 ` Ezequiel Garcia
2020-08-10 17:05           ` Jernej Škrabec
2020-08-10 19:30             ` Ezequiel Garcia
2020-08-10 19:34               ` Jernej Škrabec
2020-08-10 20:08                 ` Ezequiel Garcia
2020-08-11 22:06                 ` Ezequiel Garcia
2020-08-06 15:13 ` [PATCH v2 04/14] media: uapi: h264: Clarify pic_order_cnt_bit_size field Ezequiel Garcia
2020-08-06 15:13 ` [PATCH v2 05/14] media: uapi: h264: Increase size of 'first_mb_in_slice' field Ezequiel Garcia
2020-08-06 15:13 ` [PATCH v2 06/14] media: uapi: h264: Clean DPB entry interface Ezequiel Garcia
2020-08-06 15:13 ` [PATCH v2 07/14] media: uapi: h264: Increase size of DPB entry pic_num Ezequiel Garcia
2020-08-06 15:13 ` [PATCH v2 08/14] media: uapi: h264: Drop SLICE_PARAMS 'size' field Ezequiel Garcia
2020-08-06 15:50   ` Paul Kocialkowski
2020-08-07 14:44     ` Ezequiel Garcia
2020-08-19 13:54       ` Paul Kocialkowski
2020-08-20  7:32         ` Ezequiel Garcia
2020-08-28 14:21           ` Nicolas Dufresne
2020-08-06 15:13 ` Ezequiel Garcia [this message]
2020-08-06 15:52   ` [PATCH v2 09/14] media: uapi: h264: Clarify SLICE_BASED mode Paul Kocialkowski
2020-08-06 15:13 ` [PATCH v2 10/14] media: uapi: h264: Clean slice invariants syntax elements Ezequiel Garcia
2020-08-06 15:13 ` [PATCH v2 11/14] media: hantro: Don't require unneeded H264_SLICE_PARAMS Ezequiel Garcia
2020-08-06 15:13 ` [PATCH v2 12/14] media: rkvdec: " Ezequiel Garcia
2020-08-06 15:13 ` [PATCH v2 13/14] media: cedrus: h264: Properly configure reference field Ezequiel Garcia
2020-08-06 15:13 ` [PATCH v2 14/14] media: cedrus: h264: Fix frame list construction Ezequiel Garcia
2020-08-11 19:16 ` [PATCH v2 00/14] Clean H264 stateless uAPI Jernej Škrabec

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200806151310.98624-10-ezequiel@collabora.com \
    --to=ezequiel@collabora.com \
    --cc=acourbot@chromium.org \
    --cc=hverkuil@xs4all.nl \
    --cc=jernej.skrabec@siol.net \
    --cc=jkardatzke@chromium.org \
    --cc=jonas@kwiboo.se \
    --cc=kernel@collabora.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mripard@kernel.org \
    --cc=nicolas.dufresne@collabora.com \
    --cc=p.zabel@pengutronix.de \
    --cc=paul.kocialkowski@bootlin.com \
    --cc=tfiga@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).