linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC] media: uapi: Move HEVC stateless controls out of staging
@ 2022-02-01 12:34 Benjamin Gaignard
  2022-02-13 11:33 ` Jernej Škrabec
  0 siblings, 1 reply; 8+ messages in thread
From: Benjamin Gaignard @ 2022-02-01 12:34 UTC (permalink / raw)
  To: mchehab, ezequiel, p.zabel, gregkh, mripard, paul.kocialkowski,
	wens, jernej.skrabec, hverkuil-cisco, jonas, nicolas
  Cc: linux-media, linux-kernel, linux-staging, linux-arm-kernel,
	linux-sunxi, kernel, Benjamin Gaignard

The HEVC stateless 'uAPI' was staging and marked explicitly in the
V4L2 specification that it will change and is unstable.

Note that these control IDs were never exported as a public API,
they were only defined in kernel-local headers (hevc-ctrls.h).

While moving the controls out of staging they are renamed and
control IDs get new numbers.
Drivers (Hantro, Cedrus) and Documentation are updated accordaly.

Additional structures fields has been added for RKVDEC driver usage.
Hantro dedicated control is moving to hantro-media.h
Since hevc-ctrls.h content has been dispatched in others file, remove it.

fluster tests results on IMX8MQ is 77/147 for HEVC codec.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
---
 .../media/v4l/ext-ctrls-codec.rst             |  50 +++-
 drivers/media/v4l2-core/v4l2-ctrls-defs.c     |  32 +--
 drivers/staging/media/hantro/hantro_drv.c     |  27 +-
 drivers/staging/media/hantro/hantro_hevc.c    |   8 +-
 drivers/staging/media/sunxi/cedrus/cedrus.c   |  24 +-
 .../staging/media/sunxi/cedrus/cedrus_dec.c   |  10 +-
 include/linux/hantro-media.h                  |  17 ++
 include/media/hevc-ctrls.h                    | 250 ------------------
 include/media/v4l2-ctrls.h                    |   6 -
 include/uapi/linux/v4l2-controls.h            | 226 ++++++++++++++++
 include/uapi/linux/videodev2.h                |   7 +
 11 files changed, 338 insertions(+), 319 deletions(-)
 create mode 100644 include/linux/hantro-media.h
 delete mode 100644 include/media/hevc-ctrls.h

diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index 4cd7c541fc30..845ac660fea9 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -2639,7 +2639,7 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
 
 .. _v4l2-mpeg-hevc:
 
-``V4L2_CID_MPEG_VIDEO_HEVC_SPS (struct)``
+``V4L2_CID_STATELESS_HEVC_SPS (struct)``
     Specifies the Sequence Parameter Set fields (as extracted from the
     bitstream) for the associated HEVC slice data.
     These bitstream parameters are defined according to :ref:`hevc`.
@@ -2661,6 +2661,13 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
     :stub-columns: 0
     :widths:       1 1 2
 
+    * - __u8
+      - ``video_parameter_set_id``
+      - Identifies the VPS for reference by other syntax elements.
+    * - __u8
+      - ``seq_parameter_set_id``
+      - Provides an identifier for the SPS for reference by other syntax
+        elements.
     * - __u16
       - ``pic_width_in_luma_samples``
       -
@@ -2782,7 +2789,7 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
 
     \normalsize
 
-``V4L2_CID_MPEG_VIDEO_HEVC_PPS (struct)``
+``V4L2_CID_STATELESS_HEVC_PPS (struct)``
     Specifies the Picture Parameter Set fields (as extracted from the
     bitstream) for the associated HEVC slice data.
     These bitstream parameters are defined according to :ref:`hevc`.
@@ -2800,6 +2807,9 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
     :stub-columns: 0
     :widths:       1 1 2
 
+    * - __u8
+      - ``pic_parameter_set_id``
+      - Identifies the PPS for reference by other syntax elements.
     * - __u8
       - ``num_extra_slice_header_bits``
       -
@@ -2932,7 +2942,7 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
 
     \normalsize
 
-``V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS (struct)``
+``V4L2_CID_STATELESS_HEVC_SLICE_PARAMS (struct)``
     Specifies various slice-specific parameters, especially from the NAL unit
     header, general slice segment header and weighted prediction parameter
     parts of the bitstream.
@@ -3026,6 +3036,20 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
     * - __u8
       - ``ref_idx_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
       - The list of L1 reference elements as indices in the DPB.
+    * - __u16
+      - ``short_term_ref_pic_set_size``
+      -
+    * - __u16
+      - ``long_term_ref_pic_set_size``
+      -
+    * - __u32
+      - ``num_entry_point_offsets``
+      - Specifies the number of entry_point_offset_minus1[ i ]
+        syntax elements in the slice header.
+    * - __u32
+      - ``entry_point_offset_minus1``
+      - Plus 1 specifies the i-th entry point offset in bytes and
+        is represented by offset_len_minus1 plus 1 bits.
     * - __u8
       - ``padding``
       - Applications and drivers must set this to zero.
@@ -3088,7 +3112,7 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
 
     \normalsize
 
-``V4L2_CID_MPEG_VIDEO_HEVC_SCALING_MATRIX (struct)``
+``V4L2_CID_STATELESS_HEVC_SCALING_MATRIX (struct)``
     Specifies the HEVC scaling matrix parameters used for the scaling process
     for transform coefficients.
     These matrix and parameters are defined according to :ref:`hevc`.
@@ -3238,7 +3262,7 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
 
     \normalsize
 
-``V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE (enum)``
+``V4L2_CID_STATELESS_HEVC_DECODE_MODE (enum)``
     Specifies the decoding mode to use. Currently exposes slice-based and
     frame-based decoding but new modes might be added later on.
     This control is used as a modifier for V4L2_PIX_FMT_HEVC_SLICE
@@ -3253,7 +3277,7 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
        This menu control is not yet part of the public kernel API and
        it is expected to change.
 
-.. c:type:: v4l2_mpeg_video_hevc_decode_mode
+.. c:type:: v4l2_stateless_hevc_decode_mode
 
 .. raw:: latex
 
@@ -3266,11 +3290,11 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
     :stub-columns: 0
     :widths:       1 1 2
 
-    * - ``V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_SLICE_BASED``
+    * - ``V4L2_STATELESS_HEVC_DECODE_MODE_SLICE_BASED``
       - 0
       - Decoding is done at the slice granularity.
         The OUTPUT buffer must contain a single slice.
-    * - ``V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_FRAME_BASED``
+    * - ``V4L2_STATELESS_HEVC_DECODE_MODE_FRAME_BASED``
       - 1
       - Decoding is done at the frame granularity.
         The OUTPUT buffer must contain all slices needed to decode the
@@ -3280,7 +3304,7 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
 
     \normalsize
 
-``V4L2_CID_MPEG_VIDEO_HEVC_START_CODE (enum)``
+``V4L2_CID_STATELESS_HEVC_START_CODE (enum)``
     Specifies the HEVC slice start code expected for each slice.
     This control is used as a modifier for V4L2_PIX_FMT_HEVC_SLICE
     pixel format. Applications that support V4L2_PIX_FMT_HEVC_SLICE
@@ -3294,7 +3318,7 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
        This menu control is not yet part of the public kernel API and
        it is expected to change.
 
-.. c:type:: v4l2_mpeg_video_hevc_start_code
+.. c:type:: v4l2_stateless_hevc_start_code
 
 .. tabularcolumns:: |p{9.2cm}|p{0.6cm}|p{7.5cm}|
 
@@ -3303,13 +3327,13 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
     :stub-columns: 0
     :widths:       1 1 2
 
-    * - ``V4L2_MPEG_VIDEO_HEVC_START_CODE_NONE``
+    * - ``V4L2_STATELESS_HEVC_START_CODE_NONE``
       - 0
       - Selecting this value specifies that HEVC slices are passed
         to the driver without any start code. The bitstream data should be
         according to :ref:`hevc` 7.3.1.1 General NAL unit syntax, hence
         contains emulation prevention bytes when required.
-    * - ``V4L2_MPEG_VIDEO_HEVC_START_CODE_ANNEX_B``
+    * - ``V4L2_STATELESS_HEVC_START_CODE_ANNEX_B``
       - 1
       - Selecting this value specifies that HEVC slices are expected
         to be prefixed by Annex B start codes. According to :ref:`hevc`
@@ -3342,7 +3366,7 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
     This provides a bitmask which consists of bits [0, LTR_COUNT-1].
     This is applicable to the H264 and HEVC encoders.
 
-``V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS (struct)``
+``V4L2_CID_STATELESS_HEVC_DECODE_PARAMS (struct)``
     Specifies various decode parameters, especially the references picture order
     count (POC) for all the lists (short, long, before, current, after) and the
     number of entries for each of them.
diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
index 54ca4e6b820b..4b68cbe23309 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
@@ -699,9 +699,9 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
 		return hevc_tier;
 	case V4L2_CID_MPEG_VIDEO_HEVC_LOOP_FILTER_MODE:
 		return hevc_loop_filter_mode;
-	case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE:
+	case V4L2_CID_STATELESS_HEVC_DECODE_MODE:
 		return hevc_decode_mode;
-	case V4L2_CID_MPEG_VIDEO_HEVC_START_CODE:
+	case V4L2_CID_STATELESS_HEVC_START_CODE:
 		return hevc_start_code;
 	case V4L2_CID_CAMERA_ORIENTATION:
 		return camera_orientation;
@@ -995,13 +995,6 @@ const char *v4l2_ctrl_get_name(u32 id)
 	case V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD:	return "HEVC Size of Length Field";
 	case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:	return "Reference Frames for a P-Frame";
 	case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:		return "Prepend SPS and PPS to IDR";
-	case V4L2_CID_MPEG_VIDEO_HEVC_SPS:			return "HEVC Sequence Parameter Set";
-	case V4L2_CID_MPEG_VIDEO_HEVC_PPS:			return "HEVC Picture Parameter Set";
-	case V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS:		return "HEVC Slice Parameters";
-	case V4L2_CID_MPEG_VIDEO_HEVC_SCALING_MATRIX:		return "HEVC Scaling Matrix";
-	case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS:		return "HEVC Decode Parameters";
-	case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE:		return "HEVC Decode Mode";
-	case V4L2_CID_MPEG_VIDEO_HEVC_START_CODE:		return "HEVC Start Code";
 
 	/* CAMERA controls */
 	/* Keep the order of the 'case's the same as in v4l2-controls.h! */
@@ -1180,6 +1173,13 @@ const char *v4l2_ctrl_get_name(u32 id)
 	case V4L2_CID_STATELESS_MPEG2_QUANTISATION:		return "MPEG-2 Quantisation Matrices";
 	case V4L2_CID_STATELESS_VP9_COMPRESSED_HDR:	return "VP9 Probabilities Updates";
 	case V4L2_CID_STATELESS_VP9_FRAME:			return "VP9 Frame Decode Parameters";
+	case V4L2_CID_STATELESS_HEVC_SPS:			return "HEVC Sequence Parameter Set";
+	case V4L2_CID_STATELESS_HEVC_PPS:			return "HEVC Picture Parameter Set";
+	case V4L2_CID_STATELESS_HEVC_SLICE_PARAMS:		return "HEVC Slice Parameters";
+	case V4L2_CID_STATELESS_HEVC_SCALING_MATRIX:		return "HEVC Scaling Matrix";
+	case V4L2_CID_STATELESS_HEVC_DECODE_PARAMS:		return "HEVC Decode Parameters";
+	case V4L2_CID_STATELESS_HEVC_DECODE_MODE:		return "HEVC Decode Mode";
+	case V4L2_CID_STATELESS_HEVC_START_CODE:		return "HEVC Start Code";
 
 	/* Colorimetry controls */
 	/* Keep the order of the 'case's the same as in v4l2-controls.h! */
@@ -1355,8 +1355,8 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
 	case V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD:
 	case V4L2_CID_MPEG_VIDEO_HEVC_TIER:
 	case V4L2_CID_MPEG_VIDEO_HEVC_LOOP_FILTER_MODE:
-	case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE:
-	case V4L2_CID_MPEG_VIDEO_HEVC_START_CODE:
+	case V4L2_CID_STATELESS_HEVC_DECODE_MODE:
+	case V4L2_CID_STATELESS_HEVC_START_CODE:
 	case V4L2_CID_STATELESS_H264_DECODE_MODE:
 	case V4L2_CID_STATELESS_H264_START_CODE:
 	case V4L2_CID_CAMERA_ORIENTATION:
@@ -1493,19 +1493,19 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
 	case V4L2_CID_STATELESS_VP8_FRAME:
 		*type = V4L2_CTRL_TYPE_VP8_FRAME;
 		break;
-	case V4L2_CID_MPEG_VIDEO_HEVC_SPS:
+	case V4L2_CID_STATELESS_HEVC_SPS:
 		*type = V4L2_CTRL_TYPE_HEVC_SPS;
 		break;
-	case V4L2_CID_MPEG_VIDEO_HEVC_PPS:
+	case V4L2_CID_STATELESS_HEVC_PPS:
 		*type = V4L2_CTRL_TYPE_HEVC_PPS;
 		break;
-	case V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS:
+	case V4L2_CID_STATELESS_HEVC_SLICE_PARAMS:
 		*type = V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS;
 		break;
-	case V4L2_CID_MPEG_VIDEO_HEVC_SCALING_MATRIX:
+	case V4L2_CID_STATELESS_HEVC_SCALING_MATRIX:
 		*type = V4L2_CTRL_TYPE_HEVC_SCALING_MATRIX;
 		break;
-	case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS:
+	case V4L2_CID_STATELESS_HEVC_DECODE_PARAMS:
 		*type = V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS;
 		break;
 	case V4L2_CID_STATELESS_VP9_COMPRESSED_HDR:
diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index 8f020ba15194..fc609a59585e 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -11,6 +11,7 @@
  */
 
 #include <linux/clk.h>
+#include <linux/hantro-media.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
@@ -261,7 +262,7 @@ static int hantro_try_ctrl(struct v4l2_ctrl *ctrl)
 		if (sps->bit_depth_luma_minus8 != 0)
 			/* Only 8-bit is supported */
 			return -EINVAL;
-	} else if (ctrl->id == V4L2_CID_MPEG_VIDEO_HEVC_SPS) {
+	} else if (ctrl->id == V4L2_CID_STATELESS_HEVC_SPS) {
 		const struct v4l2_ctrl_hevc_sps *sps = ctrl->p_new.p_hevc_sps;
 
 		if (sps->bit_depth_luma_minus8 != sps->bit_depth_chroma_minus8)
@@ -413,18 +414,18 @@ static const struct hantro_ctrl controls[] = {
 	}, {
 		.codec = HANTRO_HEVC_DECODER,
 		.cfg = {
-			.id = V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE,
-			.min = V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_FRAME_BASED,
-			.max = V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_FRAME_BASED,
-			.def = V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_FRAME_BASED,
+			.id = V4L2_CID_STATELESS_HEVC_DECODE_MODE,
+			.min = V4L2_STATELESS_HEVC_DECODE_MODE_FRAME_BASED,
+			.max = V4L2_STATELESS_HEVC_DECODE_MODE_FRAME_BASED,
+			.def = V4L2_STATELESS_HEVC_DECODE_MODE_FRAME_BASED,
 		},
 	}, {
 		.codec = HANTRO_HEVC_DECODER,
 		.cfg = {
-			.id = V4L2_CID_MPEG_VIDEO_HEVC_START_CODE,
-			.min = V4L2_MPEG_VIDEO_HEVC_START_CODE_ANNEX_B,
-			.max = V4L2_MPEG_VIDEO_HEVC_START_CODE_ANNEX_B,
-			.def = V4L2_MPEG_VIDEO_HEVC_START_CODE_ANNEX_B,
+			.id = V4L2_CID_STATELESS_HEVC_START_CODE,
+			.min = V4L2_STATELESS_HEVC_START_CODE_ANNEX_B,
+			.max = V4L2_STATELESS_HEVC_START_CODE_ANNEX_B,
+			.def = V4L2_STATELESS_HEVC_START_CODE_ANNEX_B,
 		},
 	}, {
 		.codec = HANTRO_HEVC_DECODER,
@@ -444,23 +445,23 @@ static const struct hantro_ctrl controls[] = {
 	}, {
 		.codec = HANTRO_HEVC_DECODER,
 		.cfg = {
-			.id = V4L2_CID_MPEG_VIDEO_HEVC_SPS,
+			.id = V4L2_CID_STATELESS_HEVC_SPS,
 			.ops = &hantro_ctrl_ops,
 		},
 	}, {
 		.codec = HANTRO_HEVC_DECODER,
 		.cfg = {
-			.id = V4L2_CID_MPEG_VIDEO_HEVC_PPS,
+			.id = V4L2_CID_STATELESS_HEVC_PPS,
 		},
 	}, {
 		.codec = HANTRO_HEVC_DECODER,
 		.cfg = {
-			.id = V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS,
+			.id = V4L2_CID_STATELESS_HEVC_DECODE_PARAMS,
 		},
 	}, {
 		.codec = HANTRO_HEVC_DECODER,
 		.cfg = {
-			.id = V4L2_CID_MPEG_VIDEO_HEVC_SCALING_MATRIX,
+			.id = V4L2_CID_STATELESS_HEVC_SCALING_MATRIX,
 		},
 	}, {
 		.codec = HANTRO_HEVC_DECODER,
diff --git a/drivers/staging/media/hantro/hantro_hevc.c b/drivers/staging/media/hantro/hantro_hevc.c
index b49a41d7ae91..b6ec86d03d91 100644
--- a/drivers/staging/media/hantro/hantro_hevc.c
+++ b/drivers/staging/media/hantro/hantro_hevc.c
@@ -201,22 +201,22 @@ int hantro_hevc_dec_prepare_run(struct hantro_ctx *ctx)
 	hantro_start_prepare_run(ctx);
 
 	ctrls->decode_params =
-		hantro_get_ctrl(ctx, V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS);
+		hantro_get_ctrl(ctx, V4L2_CID_STATELESS_HEVC_DECODE_PARAMS);
 	if (WARN_ON(!ctrls->decode_params))
 		return -EINVAL;
 
 	ctrls->scaling =
-		hantro_get_ctrl(ctx, V4L2_CID_MPEG_VIDEO_HEVC_SCALING_MATRIX);
+		hantro_get_ctrl(ctx, V4L2_CID_STATELESS_HEVC_SCALING_MATRIX);
 	if (WARN_ON(!ctrls->scaling))
 		return -EINVAL;
 
 	ctrls->sps =
-		hantro_get_ctrl(ctx, V4L2_CID_MPEG_VIDEO_HEVC_SPS);
+		hantro_get_ctrl(ctx, V4L2_CID_STATELESS_HEVC_SPS);
 	if (WARN_ON(!ctrls->sps))
 		return -EINVAL;
 
 	ctrls->pps =
-		hantro_get_ctrl(ctx, V4L2_CID_MPEG_VIDEO_HEVC_PPS);
+		hantro_get_ctrl(ctx, V4L2_CID_STATELESS_HEVC_PPS);
 	if (WARN_ON(!ctrls->pps))
 		return -EINVAL;
 
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 4a4b714b0f26..e0428163f82c 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -42,7 +42,7 @@ static int cedrus_try_ctrl(struct v4l2_ctrl *ctrl)
 		if (sps->bit_depth_luma_minus8 != 0)
 			/* Only 8-bit is supported */
 			return -EINVAL;
-	} else if (ctrl->id == V4L2_CID_MPEG_VIDEO_HEVC_SPS) {
+	} else if (ctrl->id == V4L2_CID_STATELESS_HEVC_SPS) {
 		const struct v4l2_ctrl_hevc_sps *sps = ctrl->p_new.p_hevc_sps;
 		struct cedrus_ctx *ctx = container_of(ctrl->handler, struct cedrus_ctx, hdl);
 
@@ -164,42 +164,42 @@ static const struct cedrus_control cedrus_controls[] = {
 	},
 	{
 		.cfg = {
-			.id	= V4L2_CID_MPEG_VIDEO_HEVC_SPS,
+			.id	= V4L2_CID_STATELESS_HEVC_SPS,
 			.ops	= &cedrus_ctrl_ops,
 		},
 		.codec		= CEDRUS_CODEC_H265,
 	},
 	{
 		.cfg = {
-			.id	= V4L2_CID_MPEG_VIDEO_HEVC_PPS,
+			.id	= V4L2_CID_STATELESS_HEVC_PPS,
 		},
 		.codec		= CEDRUS_CODEC_H265,
 	},
 	{
 		.cfg = {
-			.id	= V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS,
+			.id	= V4L2_CID_STATELESS_HEVC_SLICE_PARAMS,
 		},
 		.codec		= CEDRUS_CODEC_H265,
 	},
 	{
 		.cfg = {
-			.id	= V4L2_CID_MPEG_VIDEO_HEVC_SCALING_MATRIX,
+			.id	= V4L2_CID_STATELESS_HEVC_SCALING_MATRIX,
 		},
 		.codec		= CEDRUS_CODEC_H265,
 	},
 	{
 		.cfg = {
-			.id	= V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE,
-			.max	= V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_SLICE_BASED,
-			.def	= V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_SLICE_BASED,
+			.id	= V4L2_CID_STATELESS_HEVC_DECODE_MODE,
+			.max	= V4L2_STATELESS_HEVC_DECODE_MODE_SLICE_BASED,
+			.def	= V4L2_STATELESS_HEVC_DECODE_MODE_SLICE_BASED,
 		},
 		.codec		= CEDRUS_CODEC_H265,
 	},
 	{
 		.cfg = {
-			.id	= V4L2_CID_MPEG_VIDEO_HEVC_START_CODE,
-			.max	= V4L2_MPEG_VIDEO_HEVC_START_CODE_NONE,
-			.def	= V4L2_MPEG_VIDEO_HEVC_START_CODE_NONE,
+			.id	= V4L2_CID_STATELESS_HEVC_START_CODE,
+			.max	= V4L2_STATELESS_HEVC_START_CODE_NONE,
+			.def	= V4L2_STATELESS_HEVC_START_CODE_NONE,
 		},
 		.codec		= CEDRUS_CODEC_H265,
 	},
@@ -211,7 +211,7 @@ static const struct cedrus_control cedrus_controls[] = {
 	},
 	{
 		.cfg = {
-			.id = V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS,
+			.id = V4L2_CID_STATELESS_HEVC_DECODE_PARAMS,
 		},
 		.codec		= CEDRUS_CODEC_H265,
 	},
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index a16c1422558f..f6be4ae72ee2 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -65,15 +65,15 @@ void cedrus_device_run(void *priv)
 
 	case V4L2_PIX_FMT_HEVC_SLICE:
 		run.h265.sps = cedrus_find_control_data(ctx,
-			V4L2_CID_MPEG_VIDEO_HEVC_SPS);
+			V4L2_CID_STATELESS_HEVC_SPS);
 		run.h265.pps = cedrus_find_control_data(ctx,
-			V4L2_CID_MPEG_VIDEO_HEVC_PPS);
+			V4L2_CID_STATELESS_HEVC_PPS);
 		run.h265.slice_params = cedrus_find_control_data(ctx,
-			V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS);
+			V4L2_CID_STATELESS_HEVC_SLICE_PARAMS);
 		run.h265.decode_params = cedrus_find_control_data(ctx,
-			V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS);
+			V4L2_CID_STATELESS_HEVC_DECODE_PARAMS);
 		run.h265.scaling_matrix = cedrus_find_control_data(ctx,
-			V4L2_CID_MPEG_VIDEO_HEVC_SCALING_MATRIX);
+			V4L2_CID_STATELESS_HEVC_SCALING_MATRIX);
 		break;
 
 	case V4L2_PIX_FMT_VP8_FRAME:
diff --git a/include/linux/hantro-media.h b/include/linux/hantro-media.h
new file mode 100644
index 000000000000..db2791ab7c3b
--- /dev/null
+++ b/include/linux/hantro-media.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#ifndef __LINUX_HANTRO_MEDIA_H__
+#define __LINUX_HANTRO_MEDIA_H__
+
+/*
+ * V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP -
+ * the number of data (in bits) to skip in the
+ * slice segment header.
+ * If non-IDR, the bits to be skipped go from syntax element "pic_output_flag"
+ * to before syntax element "slice_temporal_mvp_enabled_flag".
+ * If IDR, the skipped bits are just "pic_output_flag"
+ * (separate_colour_plane_flag is not supported).
+ */
+#define V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP	(V4L2_CID_USER_HANTRO_BASE + 0)
+
+#endif
diff --git a/include/media/hevc-ctrls.h b/include/media/hevc-ctrls.h
deleted file mode 100644
index 01ccda48d8c5..000000000000
--- a/include/media/hevc-ctrls.h
+++ /dev/null
@@ -1,250 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * These are the HEVC state controls for use with stateless HEVC
- * codec drivers.
- *
- * It turns out that these structs are not stable yet and will undergo
- * more changes. So keep them private until they are stable and ready to
- * become part of the official public API.
- */
-
-#ifndef _HEVC_CTRLS_H_
-#define _HEVC_CTRLS_H_
-
-#include <linux/videodev2.h>
-
-/* The pixel format isn't stable at the moment and will likely be renamed. */
-#define V4L2_PIX_FMT_HEVC_SLICE v4l2_fourcc('S', '2', '6', '5') /* HEVC parsed slices */
-
-#define V4L2_CID_MPEG_VIDEO_HEVC_SPS		(V4L2_CID_CODEC_BASE + 1008)
-#define V4L2_CID_MPEG_VIDEO_HEVC_PPS		(V4L2_CID_CODEC_BASE + 1009)
-#define V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS	(V4L2_CID_CODEC_BASE + 1010)
-#define V4L2_CID_MPEG_VIDEO_HEVC_SCALING_MATRIX	(V4L2_CID_CODEC_BASE + 1011)
-#define V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS	(V4L2_CID_CODEC_BASE + 1012)
-#define V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE	(V4L2_CID_CODEC_BASE + 1015)
-#define V4L2_CID_MPEG_VIDEO_HEVC_START_CODE	(V4L2_CID_CODEC_BASE + 1016)
-
-/* enum v4l2_ctrl_type type values */
-#define V4L2_CTRL_TYPE_HEVC_SPS 0x0120
-#define V4L2_CTRL_TYPE_HEVC_PPS 0x0121
-#define V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS 0x0122
-#define V4L2_CTRL_TYPE_HEVC_SCALING_MATRIX 0x0123
-#define V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS 0x0124
-
-enum v4l2_mpeg_video_hevc_decode_mode {
-	V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_SLICE_BASED,
-	V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_FRAME_BASED,
-};
-
-enum v4l2_mpeg_video_hevc_start_code {
-	V4L2_MPEG_VIDEO_HEVC_START_CODE_NONE,
-	V4L2_MPEG_VIDEO_HEVC_START_CODE_ANNEX_B,
-};
-
-#define V4L2_HEVC_SLICE_TYPE_B	0
-#define V4L2_HEVC_SLICE_TYPE_P	1
-#define V4L2_HEVC_SLICE_TYPE_I	2
-
-#define V4L2_HEVC_SPS_FLAG_SEPARATE_COLOUR_PLANE		(1ULL << 0)
-#define V4L2_HEVC_SPS_FLAG_SCALING_LIST_ENABLED			(1ULL << 1)
-#define V4L2_HEVC_SPS_FLAG_AMP_ENABLED				(1ULL << 2)
-#define V4L2_HEVC_SPS_FLAG_SAMPLE_ADAPTIVE_OFFSET		(1ULL << 3)
-#define V4L2_HEVC_SPS_FLAG_PCM_ENABLED				(1ULL << 4)
-#define V4L2_HEVC_SPS_FLAG_PCM_LOOP_FILTER_DISABLED		(1ULL << 5)
-#define V4L2_HEVC_SPS_FLAG_LONG_TERM_REF_PICS_PRESENT		(1ULL << 6)
-#define V4L2_HEVC_SPS_FLAG_SPS_TEMPORAL_MVP_ENABLED		(1ULL << 7)
-#define V4L2_HEVC_SPS_FLAG_STRONG_INTRA_SMOOTHING_ENABLED	(1ULL << 8)
-
-/* The controls are not stable at the moment and will likely be reworked. */
-struct v4l2_ctrl_hevc_sps {
-	/* ISO/IEC 23008-2, ITU-T Rec. H.265: Sequence parameter set */
-	__u16	pic_width_in_luma_samples;
-	__u16	pic_height_in_luma_samples;
-	__u8	bit_depth_luma_minus8;
-	__u8	bit_depth_chroma_minus8;
-	__u8	log2_max_pic_order_cnt_lsb_minus4;
-	__u8	sps_max_dec_pic_buffering_minus1;
-	__u8	sps_max_num_reorder_pics;
-	__u8	sps_max_latency_increase_plus1;
-	__u8	log2_min_luma_coding_block_size_minus3;
-	__u8	log2_diff_max_min_luma_coding_block_size;
-	__u8	log2_min_luma_transform_block_size_minus2;
-	__u8	log2_diff_max_min_luma_transform_block_size;
-	__u8	max_transform_hierarchy_depth_inter;
-	__u8	max_transform_hierarchy_depth_intra;
-	__u8	pcm_sample_bit_depth_luma_minus1;
-	__u8	pcm_sample_bit_depth_chroma_minus1;
-	__u8	log2_min_pcm_luma_coding_block_size_minus3;
-	__u8	log2_diff_max_min_pcm_luma_coding_block_size;
-	__u8	num_short_term_ref_pic_sets;
-	__u8	num_long_term_ref_pics_sps;
-	__u8	chroma_format_idc;
-	__u8	sps_max_sub_layers_minus1;
-
-	__u64	flags;
-};
-
-#define V4L2_HEVC_PPS_FLAG_DEPENDENT_SLICE_SEGMENT_ENABLED	(1ULL << 0)
-#define V4L2_HEVC_PPS_FLAG_OUTPUT_FLAG_PRESENT			(1ULL << 1)
-#define V4L2_HEVC_PPS_FLAG_SIGN_DATA_HIDING_ENABLED		(1ULL << 2)
-#define V4L2_HEVC_PPS_FLAG_CABAC_INIT_PRESENT			(1ULL << 3)
-#define V4L2_HEVC_PPS_FLAG_CONSTRAINED_INTRA_PRED		(1ULL << 4)
-#define V4L2_HEVC_PPS_FLAG_TRANSFORM_SKIP_ENABLED		(1ULL << 5)
-#define V4L2_HEVC_PPS_FLAG_CU_QP_DELTA_ENABLED			(1ULL << 6)
-#define V4L2_HEVC_PPS_FLAG_PPS_SLICE_CHROMA_QP_OFFSETS_PRESENT	(1ULL << 7)
-#define V4L2_HEVC_PPS_FLAG_WEIGHTED_PRED			(1ULL << 8)
-#define V4L2_HEVC_PPS_FLAG_WEIGHTED_BIPRED			(1ULL << 9)
-#define V4L2_HEVC_PPS_FLAG_TRANSQUANT_BYPASS_ENABLED		(1ULL << 10)
-#define V4L2_HEVC_PPS_FLAG_TILES_ENABLED			(1ULL << 11)
-#define V4L2_HEVC_PPS_FLAG_ENTROPY_CODING_SYNC_ENABLED		(1ULL << 12)
-#define V4L2_HEVC_PPS_FLAG_LOOP_FILTER_ACROSS_TILES_ENABLED	(1ULL << 13)
-#define V4L2_HEVC_PPS_FLAG_PPS_LOOP_FILTER_ACROSS_SLICES_ENABLED (1ULL << 14)
-#define V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_OVERRIDE_ENABLED	(1ULL << 15)
-#define V4L2_HEVC_PPS_FLAG_PPS_DISABLE_DEBLOCKING_FILTER	(1ULL << 16)
-#define V4L2_HEVC_PPS_FLAG_LISTS_MODIFICATION_PRESENT		(1ULL << 17)
-#define V4L2_HEVC_PPS_FLAG_SLICE_SEGMENT_HEADER_EXTENSION_PRESENT (1ULL << 18)
-#define V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT	(1ULL << 19)
-#define V4L2_HEVC_PPS_FLAG_UNIFORM_SPACING			(1ULL << 20)
-
-struct v4l2_ctrl_hevc_pps {
-	/* ISO/IEC 23008-2, ITU-T Rec. H.265: Picture parameter set */
-	__u8	num_extra_slice_header_bits;
-	__u8	num_ref_idx_l0_default_active_minus1;
-	__u8	num_ref_idx_l1_default_active_minus1;
-	__s8	init_qp_minus26;
-	__u8	diff_cu_qp_delta_depth;
-	__s8	pps_cb_qp_offset;
-	__s8	pps_cr_qp_offset;
-	__u8	num_tile_columns_minus1;
-	__u8	num_tile_rows_minus1;
-	__u8	column_width_minus1[20];
-	__u8	row_height_minus1[22];
-	__s8	pps_beta_offset_div2;
-	__s8	pps_tc_offset_div2;
-	__u8	log2_parallel_merge_level_minus2;
-
-	__u8	padding[4];
-	__u64	flags;
-};
-
-#define V4L2_HEVC_DPB_ENTRY_LONG_TERM_REFERENCE	0x01
-
-#define V4L2_HEVC_DPB_ENTRIES_NUM_MAX		16
-
-struct v4l2_hevc_dpb_entry {
-	__u64	timestamp;
-	__u8	flags;
-	__u8	field_pic;
-	__u16	pic_order_cnt[2];
-	__u8	padding[2];
-};
-
-struct v4l2_hevc_pred_weight_table {
-	__s8	delta_luma_weight_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
-	__s8	luma_offset_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
-	__s8	delta_chroma_weight_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
-	__s8	chroma_offset_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
-
-	__s8	delta_luma_weight_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
-	__s8	luma_offset_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
-	__s8	delta_chroma_weight_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
-	__s8	chroma_offset_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
-
-	__u8	padding[6];
-
-	__u8	luma_log2_weight_denom;
-	__s8	delta_chroma_log2_weight_denom;
-};
-
-#define V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_SAO_LUMA		(1ULL << 0)
-#define V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_SAO_CHROMA		(1ULL << 1)
-#define V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_TEMPORAL_MVP_ENABLED	(1ULL << 2)
-#define V4L2_HEVC_SLICE_PARAMS_FLAG_MVD_L1_ZERO			(1ULL << 3)
-#define V4L2_HEVC_SLICE_PARAMS_FLAG_CABAC_INIT			(1ULL << 4)
-#define V4L2_HEVC_SLICE_PARAMS_FLAG_COLLOCATED_FROM_L0		(1ULL << 5)
-#define V4L2_HEVC_SLICE_PARAMS_FLAG_USE_INTEGER_MV		(1ULL << 6)
-#define V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_DEBLOCKING_FILTER_DISABLED (1ULL << 7)
-#define V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_LOOP_FILTER_ACROSS_SLICES_ENABLED (1ULL << 8)
-#define V4L2_HEVC_SLICE_PARAMS_FLAG_DEPENDENT_SLICE_SEGMENT	(1ULL << 9)
-
-struct v4l2_ctrl_hevc_slice_params {
-	__u32	bit_size;
-	__u32	data_bit_offset;
-
-	/* ISO/IEC 23008-2, ITU-T Rec. H.265: NAL unit header */
-	__u8	nal_unit_type;
-	__u8	nuh_temporal_id_plus1;
-
-	/* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment header */
-	__u8	slice_type;
-	__u8	colour_plane_id;
-	__u16	slice_pic_order_cnt;
-	__u8	num_ref_idx_l0_active_minus1;
-	__u8	num_ref_idx_l1_active_minus1;
-	__u8	collocated_ref_idx;
-	__u8	five_minus_max_num_merge_cand;
-	__s8	slice_qp_delta;
-	__s8	slice_cb_qp_offset;
-	__s8	slice_cr_qp_offset;
-	__s8	slice_act_y_qp_offset;
-	__s8	slice_act_cb_qp_offset;
-	__s8	slice_act_cr_qp_offset;
-	__s8	slice_beta_offset_div2;
-	__s8	slice_tc_offset_div2;
-
-	/* ISO/IEC 23008-2, ITU-T Rec. H.265: Picture timing SEI message */
-	__u8	pic_struct;
-
-	/* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment header */
-	__u32	slice_segment_addr;
-	__u8	ref_idx_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
-	__u8	ref_idx_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
-
-	__u8	padding;
-
-	/* ISO/IEC 23008-2, ITU-T Rec. H.265: Weighted prediction parameter */
-	struct v4l2_hevc_pred_weight_table pred_weight_table;
-
-	__u64	flags;
-};
-
-#define V4L2_HEVC_DECODE_PARAM_FLAG_IRAP_PIC		0x1
-#define V4L2_HEVC_DECODE_PARAM_FLAG_IDR_PIC		0x2
-#define V4L2_HEVC_DECODE_PARAM_FLAG_NO_OUTPUT_OF_PRIOR  0x4
-
-struct v4l2_ctrl_hevc_decode_params {
-	__s32	pic_order_cnt_val;
-	__u8	num_active_dpb_entries;
-	struct	v4l2_hevc_dpb_entry dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
-	__u8	num_poc_st_curr_before;
-	__u8	num_poc_st_curr_after;
-	__u8	num_poc_lt_curr;
-	__u8	poc_st_curr_before[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
-	__u8	poc_st_curr_after[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
-	__u8	poc_lt_curr[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
-	__u64	flags;
-};
-
-struct v4l2_ctrl_hevc_scaling_matrix {
-	__u8	scaling_list_4x4[6][16];
-	__u8	scaling_list_8x8[6][64];
-	__u8	scaling_list_16x16[6][64];
-	__u8	scaling_list_32x32[2][64];
-	__u8	scaling_list_dc_coef_16x16[6];
-	__u8	scaling_list_dc_coef_32x32[2];
-};
-
-/*  MPEG-class control IDs specific to the Hantro driver as defined by V4L2 */
-#define V4L2_CID_CODEC_HANTRO_BASE				(V4L2_CTRL_CLASS_CODEC | 0x1200)
-/*
- * V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP -
- * the number of data (in bits) to skip in the
- * slice segment header.
- * If non-IDR, the bits to be skipped go from syntax element "pic_output_flag"
- * to before syntax element "slice_temporal_mvp_enabled_flag".
- * If IDR, the skipped bits are just "pic_output_flag"
- * (separate_colour_plane_flag is not supported).
- */
-#define V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP	(V4L2_CID_CODEC_HANTRO_BASE + 0)
-
-#endif
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index b3ce438f1329..37e07d204774 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -13,12 +13,6 @@
 #include <linux/videodev2.h>
 #include <media/media-request.h>
 
-/*
- * Include the stateless codec compound control definitions.
- * This will move to the public headers once this API is fully stable.
- */
-#include <media/hevc-ctrls.h>
-
 /* forward references */
 struct file;
 struct poll_table_struct;
diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
index c8e0f84d204d..cd2e122be287 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -218,6 +218,11 @@ enum v4l2_colorfx {
  * We reserve 16 controls for this driver.
  */
 #define V4L2_CID_USER_ALLEGRO_BASE		(V4L2_CID_USER_BASE + 0x1170)
+/*
+ * The base for Hantro driver controls.
+ * We reserve 128 controls for this driver.
+ */
+#define V4L2_CID_USER_HANTRO_BASE		(V4L2_CID_USER_BASE + 0x1180)
 
 /* MPEG-class control IDs */
 /* The MPEG controls are applicable to all codec controls
@@ -2302,6 +2307,227 @@ struct v4l2_ctrl_vp9_compressed_hdr {
 	struct v4l2_vp9_mv_probs mv;
 };
 
+#define V4L2_CID_STATELESS_HEVC_SPS		(V4L2_CID_CODEC_STATELESS_BASE + 400)
+#define V4L2_CID_STATELESS_HEVC_PPS		(V4L2_CID_CODEC_STATELESS_BASE + 401)
+#define V4L2_CID_STATELESS_HEVC_SLICE_PARAMS	(V4L2_CID_CODEC_STATELESS_BASE + 402)
+#define V4L2_CID_STATELESS_HEVC_SCALING_MATRIX	(V4L2_CID_CODEC_STATELESS_BASE + 403)
+#define V4L2_CID_STATELESS_HEVC_DECODE_PARAMS	(V4L2_CID_CODEC_STATELESS_BASE + 404)
+#define V4L2_CID_STATELESS_HEVC_DECODE_MODE	(V4L2_CID_CODEC_STATELESS_BASE + 405)
+#define V4L2_CID_STATELESS_HEVC_START_CODE	(V4L2_CID_CODEC_STATELESS_BASE + 406)
+
+enum v4l2_stateless_hevc_decode_mode {
+	V4L2_STATELESS_HEVC_DECODE_MODE_SLICE_BASED,
+	V4L2_STATELESS_HEVC_DECODE_MODE_FRAME_BASED,
+};
+
+enum v4l2_stateless_hevc_start_code {
+	V4L2_STATELESS_HEVC_START_CODE_NONE,
+	V4L2_STATELESS_HEVC_START_CODE_ANNEX_B,
+};
+
+#define V4L2_HEVC_SLICE_TYPE_B	0
+#define V4L2_HEVC_SLICE_TYPE_P	1
+#define V4L2_HEVC_SLICE_TYPE_I	2
+
+#define V4L2_HEVC_SPS_FLAG_SEPARATE_COLOUR_PLANE		(1ULL << 0)
+#define V4L2_HEVC_SPS_FLAG_SCALING_LIST_ENABLED			(1ULL << 1)
+#define V4L2_HEVC_SPS_FLAG_AMP_ENABLED				(1ULL << 2)
+#define V4L2_HEVC_SPS_FLAG_SAMPLE_ADAPTIVE_OFFSET		(1ULL << 3)
+#define V4L2_HEVC_SPS_FLAG_PCM_ENABLED				(1ULL << 4)
+#define V4L2_HEVC_SPS_FLAG_PCM_LOOP_FILTER_DISABLED		(1ULL << 5)
+#define V4L2_HEVC_SPS_FLAG_LONG_TERM_REF_PICS_PRESENT		(1ULL << 6)
+#define V4L2_HEVC_SPS_FLAG_SPS_TEMPORAL_MVP_ENABLED		(1ULL << 7)
+#define V4L2_HEVC_SPS_FLAG_STRONG_INTRA_SMOOTHING_ENABLED	(1ULL << 8)
+
+struct v4l2_ctrl_hevc_sps {
+	/* ISO/IEC 23008-2, ITU-T Rec. H.265: Sequence parameter set */
+	__u8	video_parameter_set_id;
+	__u8	seq_parameter_set_id;
+	__u16	pic_width_in_luma_samples;
+	__u16	pic_height_in_luma_samples;
+	__u8	bit_depth_luma_minus8;
+	__u8	bit_depth_chroma_minus8;
+	__u8	log2_max_pic_order_cnt_lsb_minus4;
+	__u8	sps_max_dec_pic_buffering_minus1;
+	__u8	sps_max_num_reorder_pics;
+	__u8	sps_max_latency_increase_plus1;
+	__u8	log2_min_luma_coding_block_size_minus3;
+	__u8	log2_diff_max_min_luma_coding_block_size;
+	__u8	log2_min_luma_transform_block_size_minus2;
+	__u8	log2_diff_max_min_luma_transform_block_size;
+	__u8	max_transform_hierarchy_depth_inter;
+	__u8	max_transform_hierarchy_depth_intra;
+	__u8	pcm_sample_bit_depth_luma_minus1;
+	__u8	pcm_sample_bit_depth_chroma_minus1;
+	__u8	log2_min_pcm_luma_coding_block_size_minus3;
+	__u8	log2_diff_max_min_pcm_luma_coding_block_size;
+	__u8	num_short_term_ref_pic_sets;
+	__u8	num_long_term_ref_pics_sps;
+	__u8	chroma_format_idc;
+	__u8	sps_max_sub_layers_minus1;
+
+	__u8	padding[6];
+	__u64	flags;
+	__u8	reserved[24];
+};
+
+#define V4L2_HEVC_PPS_FLAG_DEPENDENT_SLICE_SEGMENT_ENABLED	(1ULL << 0)
+#define V4L2_HEVC_PPS_FLAG_OUTPUT_FLAG_PRESENT			(1ULL << 1)
+#define V4L2_HEVC_PPS_FLAG_SIGN_DATA_HIDING_ENABLED		(1ULL << 2)
+#define V4L2_HEVC_PPS_FLAG_CABAC_INIT_PRESENT			(1ULL << 3)
+#define V4L2_HEVC_PPS_FLAG_CONSTRAINED_INTRA_PRED		(1ULL << 4)
+#define V4L2_HEVC_PPS_FLAG_TRANSFORM_SKIP_ENABLED		(1ULL << 5)
+#define V4L2_HEVC_PPS_FLAG_CU_QP_DELTA_ENABLED			(1ULL << 6)
+#define V4L2_HEVC_PPS_FLAG_PPS_SLICE_CHROMA_QP_OFFSETS_PRESENT	(1ULL << 7)
+#define V4L2_HEVC_PPS_FLAG_WEIGHTED_PRED			(1ULL << 8)
+#define V4L2_HEVC_PPS_FLAG_WEIGHTED_BIPRED			(1ULL << 9)
+#define V4L2_HEVC_PPS_FLAG_TRANSQUANT_BYPASS_ENABLED		(1ULL << 10)
+#define V4L2_HEVC_PPS_FLAG_TILES_ENABLED			(1ULL << 11)
+#define V4L2_HEVC_PPS_FLAG_ENTROPY_CODING_SYNC_ENABLED		(1ULL << 12)
+#define V4L2_HEVC_PPS_FLAG_LOOP_FILTER_ACROSS_TILES_ENABLED	(1ULL << 13)
+#define V4L2_HEVC_PPS_FLAG_PPS_LOOP_FILTER_ACROSS_SLICES_ENABLED (1ULL << 14)
+#define V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_OVERRIDE_ENABLED	(1ULL << 15)
+#define V4L2_HEVC_PPS_FLAG_PPS_DISABLE_DEBLOCKING_FILTER	(1ULL << 16)
+#define V4L2_HEVC_PPS_FLAG_LISTS_MODIFICATION_PRESENT		(1ULL << 17)
+#define V4L2_HEVC_PPS_FLAG_SLICE_SEGMENT_HEADER_EXTENSION_PRESENT (1ULL << 18)
+#define V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT	(1ULL << 19)
+#define V4L2_HEVC_PPS_FLAG_UNIFORM_SPACING			(1ULL << 20)
+
+struct v4l2_ctrl_hevc_pps {
+	/* ISO/IEC 23008-2, ITU-T Rec. H.265: Picture parameter set */
+	__u8	pic_parameter_set_id;
+	__u8	num_extra_slice_header_bits;
+	__u8	num_ref_idx_l0_default_active_minus1;
+	__u8	num_ref_idx_l1_default_active_minus1;
+	__s8	init_qp_minus26;
+	__u8	diff_cu_qp_delta_depth;
+	__s8	pps_cb_qp_offset;
+	__s8	pps_cr_qp_offset;
+	__u8	num_tile_columns_minus1;
+	__u8	num_tile_rows_minus1;
+	__u8	column_width_minus1[20];
+	__u8	row_height_minus1[22];
+	__s8	pps_beta_offset_div2;
+	__s8	pps_tc_offset_div2;
+	__u8	log2_parallel_merge_level_minus2;
+	__u8	padding[9];
+
+	__u64	flags;
+	__u8	reserved[56];
+};
+
+#define V4L2_HEVC_DPB_ENTRY_LONG_TERM_REFERENCE	0x01
+
+#define V4L2_HEVC_DPB_ENTRIES_NUM_MAX		16
+
+struct v4l2_hevc_dpb_entry {
+	__u64	timestamp;
+	__u8	flags;
+	__u8	field_pic;
+	__u16	pic_order_cnt[2];
+	__u8	padding[2];
+};
+
+struct v4l2_hevc_pred_weight_table {
+	__s8	delta_luma_weight_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__s8	luma_offset_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__s8	delta_chroma_weight_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
+	__s8	chroma_offset_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
+
+	__s8	delta_luma_weight_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__s8	luma_offset_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__s8	delta_chroma_weight_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
+	__s8	chroma_offset_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
+
+	__u8	padding[6];
+
+	__u8	luma_log2_weight_denom;
+	__s8	delta_chroma_log2_weight_denom;
+};
+
+#define V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_SAO_LUMA		(1ULL << 0)
+#define V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_SAO_CHROMA		(1ULL << 1)
+#define V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_TEMPORAL_MVP_ENABLED	(1ULL << 2)
+#define V4L2_HEVC_SLICE_PARAMS_FLAG_MVD_L1_ZERO			(1ULL << 3)
+#define V4L2_HEVC_SLICE_PARAMS_FLAG_CABAC_INIT			(1ULL << 4)
+#define V4L2_HEVC_SLICE_PARAMS_FLAG_COLLOCATED_FROM_L0		(1ULL << 5)
+#define V4L2_HEVC_SLICE_PARAMS_FLAG_USE_INTEGER_MV		(1ULL << 6)
+#define V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_DEBLOCKING_FILTER_DISABLED (1ULL << 7)
+#define V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_LOOP_FILTER_ACROSS_SLICES_ENABLED (1ULL << 8)
+#define V4L2_HEVC_SLICE_PARAMS_FLAG_DEPENDENT_SLICE_SEGMENT	(1ULL << 9)
+
+struct v4l2_ctrl_hevc_slice_params {
+	__u32	bit_size;
+	__u32	data_bit_offset;
+
+	/* ISO/IEC 23008-2, ITU-T Rec. H.265: NAL unit header */
+	__u8	nal_unit_type;
+	__u8	nuh_temporal_id_plus1;
+
+	/* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment header */
+	__u8	slice_type;
+	__u8	colour_plane_id;
+	__u16	slice_pic_order_cnt;
+	__u8	num_ref_idx_l0_active_minus1;
+	__u8	num_ref_idx_l1_active_minus1;
+	__u8	collocated_ref_idx;
+	__u8	five_minus_max_num_merge_cand;
+	__s8	slice_qp_delta;
+	__s8	slice_cb_qp_offset;
+	__s8	slice_cr_qp_offset;
+	__s8	slice_act_y_qp_offset;
+	__s8	slice_act_cb_qp_offset;
+	__s8	slice_act_cr_qp_offset;
+	__s8	slice_beta_offset_div2;
+	__s8	slice_tc_offset_div2;
+
+	/* ISO/IEC 23008-2, ITU-T Rec. H.265: Picture timing SEI message */
+	__u8	pic_struct;
+
+	__u8	reserved;
+
+	/* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment header */
+	__u32	slice_segment_addr;
+	__u8	ref_idx_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__u8	ref_idx_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__u16	short_term_ref_pic_set_size;
+	__u16	long_term_ref_pic_set_size;
+	__u32	num_entry_point_offsets;
+	__u32	entry_point_offset_minus1[256];
+
+	/* ISO/IEC 23008-2, ITU-T Rec. H.265: Weighted prediction parameter */
+	struct v4l2_hevc_pred_weight_table pred_weight_table;
+
+	__u64	flags;
+	__u8	padding[40];
+};
+
+#define V4L2_HEVC_DECODE_PARAM_FLAG_IRAP_PIC		0x1
+#define V4L2_HEVC_DECODE_PARAM_FLAG_IDR_PIC		0x2
+#define V4L2_HEVC_DECODE_PARAM_FLAG_NO_OUTPUT_OF_PRIOR  0x4
+
+struct v4l2_ctrl_hevc_decode_params {
+	__s32	pic_order_cnt_val;
+	__u8	num_active_dpb_entries;
+	__u8	num_poc_st_curr_before;
+	__u8	num_poc_st_curr_after;
+	__u8	num_poc_lt_curr;
+	__u8	poc_st_curr_before[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__u8	poc_st_curr_after[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__u8	poc_lt_curr[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	struct	v4l2_hevc_dpb_entry dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__u64	flags;
+};
+
+struct v4l2_ctrl_hevc_scaling_matrix {
+	__u8	scaling_list_4x4[6][16];
+	__u8	scaling_list_8x8[6][64];
+	__u8	scaling_list_16x16[6][64];
+	__u8	scaling_list_32x32[2][64];
+	__u8	scaling_list_dc_coef_16x16[6];
+	__u8	scaling_list_dc_coef_32x32[2];
+};
+
 /* MPEG-compression definitions kept for backwards compatibility */
 #ifndef __KERNEL__
 #define V4L2_CTRL_CLASS_MPEG            V4L2_CTRL_CLASS_CODEC
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index df8b9c486ba1..7a340a585334 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -708,6 +708,7 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_FWHT     v4l2_fourcc('F', 'W', 'H', 'T') /* Fast Walsh Hadamard Transform (vicodec) */
 #define V4L2_PIX_FMT_FWHT_STATELESS     v4l2_fourcc('S', 'F', 'W', 'H') /* Stateless FWHT (vicodec) */
 #define V4L2_PIX_FMT_H264_SLICE v4l2_fourcc('S', '2', '6', '4') /* H264 parsed slices */
+#define V4L2_PIX_FMT_HEVC_SLICE v4l2_fourcc('S', '2', '6', '5') /* HEVC parsed slices */
 
 /*  Vendor-specific formats   */
 #define V4L2_PIX_FMT_CPIA1    v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */
@@ -1829,6 +1830,12 @@ enum v4l2_ctrl_type {
 
 	V4L2_CTRL_TYPE_VP9_COMPRESSED_HDR	= 0x0260,
 	V4L2_CTRL_TYPE_VP9_FRAME		= 0x0261,
+
+	V4L2_CTRL_TYPE_HEVC_SPS			= 0x0270,
+	V4L2_CTRL_TYPE_HEVC_PPS			= 0x0271,
+	V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS	= 0x0272,
+	V4L2_CTRL_TYPE_HEVC_SCALING_MATRIX	= 0x0273,
+	V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS	= 0x0274,
 };
 
 /*  Used in the VIDIOC_QUERYCTRL ioctl for querying controls */
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [RFC] media: uapi: Move HEVC stateless controls out of staging
  2022-02-01 12:34 [RFC] media: uapi: Move HEVC stateless controls out of staging Benjamin Gaignard
@ 2022-02-13 11:33 ` Jernej Škrabec
  2022-02-14 10:01   ` Hans Verkuil
  2022-02-14 17:25   ` Benjamin Gaignard
  0 siblings, 2 replies; 8+ messages in thread
From: Jernej Škrabec @ 2022-02-13 11:33 UTC (permalink / raw)
  To: mchehab, ezequiel, p.zabel, gregkh, mripard, paul.kocialkowski,
	wens, hverkuil-cisco, jonas, nicolas, Benjamin Gaignard
  Cc: linux-media, linux-kernel, linux-staging, linux-arm-kernel,
	linux-sunxi, kernel, Benjamin Gaignard, Alex Bee, jc

Hi Benjamin,

CC: Alex, John

Sorry for late response, but I've been very busy last week.

First of all, thank you for doing this! It's about time that HEVC moves 
forward.

Dne torek, 01. februar 2022 ob 13:34:39 CET je Benjamin Gaignard napisal(a):
> The HEVC stateless 'uAPI' was staging and marked explicitly in the
> V4L2 specification that it will change and is unstable.
> 
> Note that these control IDs were never exported as a public API,
> they were only defined in kernel-local headers (hevc-ctrls.h).
> 
> While moving the controls out of staging they are renamed and
> control IDs get new numbers.
> Drivers (Hantro, Cedrus) and Documentation are updated accordaly.

accordaly -> accordingly

> 
> Additional structures fields has been added for RKVDEC driver usage.

You should do separate patch for that, preceding this one. One patch should 
only do one thing.

I also suggest that you add additional patch for removing bit_size field in 
struct v4l2_ctrl_hevc_slice_params. Similar fields were already removed from 
MPEG2 and H264 structures. Bit size can be deduced from output buffer size and 
it doesn't hurt if bit size in Cedrus is set to bigger value than actual slice 
bit size.

> Hantro dedicated control is moving to hantro-media.h
> Since hevc-ctrls.h content has been dispatched in others file, remove it.
> 
> fluster tests results on IMX8MQ is 77/147 for HEVC codec.
> 
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>

Note that Cedrus still needs additional information in order to decode some 
HEVC videos. Missing info is num_entry_point_offsets and list of all 
entry_point_offset_minus1 (obviously, num_entry_point_offsets in size).

I suggest that this is represented in a new control, which would use dynamic 
array feature, written by Hans. While Cedrus supports max. 256 entries, it can 
be much bigger in theory, but in reality, it's much smaller (like 4-8 
entries).

Last but not least, data_bit_offset should be better defined. Currently it 
points right after last header bit, just like Cedrus needs it. However, there 
is padding after that, at least 1 bit and 8 bits at most, so slice data always 
starts from byte aligned address. It probably make sense to rework that field 
to be byte offset, not bit, just like in VA-API. Note that RPi HEVC driver also 
uses byte aligned address directly. Cedrus would need some kind of workaround 
and only one that works is this one:
https://github.com/bootlin/libva-v4l2-request/blob/master/src/h265.c#L191-L209

Best regards,
Jernej



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC] media: uapi: Move HEVC stateless controls out of staging
  2022-02-13 11:33 ` Jernej Škrabec
@ 2022-02-14 10:01   ` Hans Verkuil
  2022-02-14 17:26     ` Benjamin Gaignard
  2022-02-14 17:25   ` Benjamin Gaignard
  1 sibling, 1 reply; 8+ messages in thread
From: Hans Verkuil @ 2022-02-14 10:01 UTC (permalink / raw)
  To: Jernej Škrabec, mchehab, ezequiel, p.zabel, gregkh, mripard,
	paul.kocialkowski, wens, jonas, nicolas, Benjamin Gaignard
  Cc: linux-media, linux-kernel, linux-staging, linux-arm-kernel,
	linux-sunxi, kernel, Alex Bee, jc

Hi all,

On 2/13/22 12:33, Jernej Škrabec wrote:
> Hi Benjamin,
> 
> CC: Alex, John
> 
> Sorry for late response, but I've been very busy last week.
> 
> First of all, thank you for doing this! It's about time that HEVC moves 
> forward.
> 
> Dne torek, 01. februar 2022 ob 13:34:39 CET je Benjamin Gaignard napisal(a):
>> The HEVC stateless 'uAPI' was staging and marked explicitly in the
>> V4L2 specification that it will change and is unstable.
>>
>> Note that these control IDs were never exported as a public API,
>> they were only defined in kernel-local headers (hevc-ctrls.h).
>>
>> While moving the controls out of staging they are renamed and
>> control IDs get new numbers.
>> Drivers (Hantro, Cedrus) and Documentation are updated accordaly.
> 
> accordaly -> accordingly
> 
>>
>> Additional structures fields has been added for RKVDEC driver usage.
> 
> You should do separate patch for that, preceding this one. One patch should 
> only do one thing.
> 
> I also suggest that you add additional patch for removing bit_size field in 
> struct v4l2_ctrl_hevc_slice_params. Similar fields were already removed from 
> MPEG2 and H264 structures. Bit size can be deduced from output buffer size and 
> it doesn't hurt if bit size in Cedrus is set to bigger value than actual slice 
> bit size.
> 
>> Hantro dedicated control is moving to hantro-media.h
>> Since hevc-ctrls.h content has been dispatched in others file, remove it.
>>
>> fluster tests results on IMX8MQ is 77/147 for HEVC codec.
>>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
> 
> Note that Cedrus still needs additional information in order to decode some 
> HEVC videos. Missing info is num_entry_point_offsets and list of all 
> entry_point_offset_minus1 (obviously, num_entry_point_offsets in size).
> 
> I suggest that this is represented in a new control, which would use dynamic 
> array feature, written by Hans. While Cedrus supports max. 256 entries, it can 
> be much bigger in theory, but in reality, it's much smaller (like 4-8 
> entries).

I've rebased my dynarray tree, so it is up to date again:

https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=dynarray

Regards,

	Hans

> 
> Last but not least, data_bit_offset should be better defined. Currently it 
> points right after last header bit, just like Cedrus needs it. However, there 
> is padding after that, at least 1 bit and 8 bits at most, so slice data always 
> starts from byte aligned address. It probably make sense to rework that field 
> to be byte offset, not bit, just like in VA-API. Note that RPi HEVC driver also 
> uses byte aligned address directly. Cedrus would need some kind of workaround 
> and only one that works is this one:
> https://github.com/bootlin/libva-v4l2-request/blob/master/src/h265.c#L191-L209
> 
> Best regards,
> Jernej
> 
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC] media: uapi: Move HEVC stateless controls out of staging
  2022-02-13 11:33 ` Jernej Škrabec
  2022-02-14 10:01   ` Hans Verkuil
@ 2022-02-14 17:25   ` Benjamin Gaignard
  2022-02-14 19:26     ` Jernej Škrabec
  1 sibling, 1 reply; 8+ messages in thread
From: Benjamin Gaignard @ 2022-02-14 17:25 UTC (permalink / raw)
  To: Jernej Škrabec, mchehab, ezequiel, p.zabel, gregkh, mripard,
	paul.kocialkowski, wens, hverkuil-cisco, jonas, nicolas
  Cc: linux-media, linux-kernel, linux-staging, linux-arm-kernel,
	linux-sunxi, kernel, Alex Bee, jc


Le 13/02/2022 à 12:33, Jernej Škrabec a écrit :
> Hi Benjamin,
>
> CC: Alex, John
>
> Sorry for late response, but I've been very busy last week.
>
> First of all, thank you for doing this! It's about time that HEVC moves
> forward.
>
> Dne torek, 01. februar 2022 ob 13:34:39 CET je Benjamin Gaignard napisal(a):
>> The HEVC stateless 'uAPI' was staging and marked explicitly in the
>> V4L2 specification that it will change and is unstable.
>>
>> Note that these control IDs were never exported as a public API,
>> they were only defined in kernel-local headers (hevc-ctrls.h).
>>
>> While moving the controls out of staging they are renamed and
>> control IDs get new numbers.
>> Drivers (Hantro, Cedrus) and Documentation are updated accordaly.
> accordaly -> accordingly
>
>> Additional structures fields has been added for RKVDEC driver usage.
> You should do separate patch for that, preceding this one. One patch should
> only do one thing.

I will do that in v2

>
> I also suggest that you add additional patch for removing bit_size field in
> struct v4l2_ctrl_hevc_slice_params. Similar fields were already removed from
> MPEG2 and H264 structures. Bit size can be deduced from output buffer size and
> it doesn't hurt if bit size in Cedrus is set to bigger value than actual slice
> bit size.

ok

>
>> Hantro dedicated control is moving to hantro-media.h
>> Since hevc-ctrls.h content has been dispatched in others file, remove it.
>>
>> fluster tests results on IMX8MQ is 77/147 for HEVC codec.
>>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
> Note that Cedrus still needs additional information in order to decode some
> HEVC videos. Missing info is num_entry_point_offsets and list of all
> entry_point_offset_minus1 (obviously, num_entry_point_offsets in size).
>
> I suggest that this is represented in a new control, which would use dynamic
> array feature, written by Hans. While Cedrus supports max. 256 entries, it can
> be much bigger in theory, but in reality, it's much smaller (like 4-8
> entries).

I haven't seen yet any user for these fields but I will create a new control like
#define V4L2_CID_STATELESS_HEVC_ENTRY_POINT	(V4L2_CID_CODEC_STATELESS_BASE + 407)

struct v4l2_ctrl_hevc_entry_point_offset {
	__u32	entry_point_offset_minus1;
};

and add it in the documentation:
``V4L2_CID_STATELESS_HEVC_ENTRY_POINT (struct)``
     Specifies the i-th entry point offset in bytes and is represented by
     offset_len_minus1 plus 1 bits.
     This control is a dynamically sized array. The number of entry point
     offsets is reported by the ``elems`` field.
     This bitstream parameter is defined according to :ref:`hevc`.
     They are described in section 7.4.7.1 "General slice segment header
     semantics" of the specification.

>
> Last but not least, data_bit_offset should be better defined. Currently it
> points right after last header bit, just like Cedrus needs it. However, there
> is padding after that, at least 1 bit and 8 bits at most, so slice data always
> starts from byte aligned address. It probably make sense to rework that field
> to be byte offset, not bit, just like in VA-API. Note that RPi HEVC driver also
> uses byte aligned address directly. Cedrus would need some kind of workaround
> and only one that works is this one:
> https://github.com/bootlin/libva-v4l2-request/blob/master/src/h265.c#L191-L209

If Cedrus driver is happy with this definition I will keep it like that.
When providing offset in bit is more accurate and any driver can align the value
if needed, the reverse (byte -> bit) isn't possible.

Regards,
Benjamin

>
> Best regards,
> Jernej
>
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC] media: uapi: Move HEVC stateless controls out of staging
  2022-02-14 10:01   ` Hans Verkuil
@ 2022-02-14 17:26     ` Benjamin Gaignard
  0 siblings, 0 replies; 8+ messages in thread
From: Benjamin Gaignard @ 2022-02-14 17:26 UTC (permalink / raw)
  To: Hans Verkuil, Jernej Škrabec, mchehab, ezequiel, p.zabel,
	gregkh, mripard, paul.kocialkowski, wens, jonas, nicolas
  Cc: linux-media, linux-kernel, linux-staging, linux-arm-kernel,
	linux-sunxi, kernel, Alex Bee, jc


Le 14/02/2022 à 11:01, Hans Verkuil a écrit :
> Hi all,
>
> On 2/13/22 12:33, Jernej Škrabec wrote:
>> Hi Benjamin,
>>
>> CC: Alex, John
>>
>> Sorry for late response, but I've been very busy last week.
>>
>> First of all, thank you for doing this! It's about time that HEVC moves
>> forward.
>>
>> Dne torek, 01. februar 2022 ob 13:34:39 CET je Benjamin Gaignard napisal(a):
>>> The HEVC stateless 'uAPI' was staging and marked explicitly in the
>>> V4L2 specification that it will change and is unstable.
>>>
>>> Note that these control IDs were never exported as a public API,
>>> they were only defined in kernel-local headers (hevc-ctrls.h).
>>>
>>> While moving the controls out of staging they are renamed and
>>> control IDs get new numbers.
>>> Drivers (Hantro, Cedrus) and Documentation are updated accordaly.
>> accordaly -> accordingly
>>
>>> Additional structures fields has been added for RKVDEC driver usage.
>> You should do separate patch for that, preceding this one. One patch should
>> only do one thing.
>>
>> I also suggest that you add additional patch for removing bit_size field in
>> struct v4l2_ctrl_hevc_slice_params. Similar fields were already removed from
>> MPEG2 and H264 structures. Bit size can be deduced from output buffer size and
>> it doesn't hurt if bit size in Cedrus is set to bigger value than actual slice
>> bit size.
>>
>>> Hantro dedicated control is moving to hantro-media.h
>>> Since hevc-ctrls.h content has been dispatched in others file, remove it.
>>>
>>> fluster tests results on IMX8MQ is 77/147 for HEVC codec.
>>>
>>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
>> Note that Cedrus still needs additional information in order to decode some
>> HEVC videos. Missing info is num_entry_point_offsets and list of all
>> entry_point_offset_minus1 (obviously, num_entry_point_offsets in size).
>>
>> I suggest that this is represented in a new control, which would use dynamic
>> array feature, written by Hans. While Cedrus supports max. 256 entries, it can
>> be much bigger in theory, but in reality, it's much smaller (like 4-8
>> entries).
> I've rebased my dynarray tree, so it is up to date again:
>
> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=dynarray

I will cheery-pick the 3 needed patches in my next version of the RFC

Thanks,
Benjamin

>
> Regards,
>
> 	Hans
>
>> Last but not least, data_bit_offset should be better defined. Currently it
>> points right after last header bit, just like Cedrus needs it. However, there
>> is padding after that, at least 1 bit and 8 bits at most, so slice data always
>> starts from byte aligned address. It probably make sense to rework that field
>> to be byte offset, not bit, just like in VA-API. Note that RPi HEVC driver also
>> uses byte aligned address directly. Cedrus would need some kind of workaround
>> and only one that works is this one:
>> https://github.com/bootlin/libva-v4l2-request/blob/master/src/h265.c#L191-L209
>>
>> Best regards,
>> Jernej
>>
>>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Re: [RFC] media: uapi: Move HEVC stateless controls out of staging
  2022-02-14 17:25   ` Benjamin Gaignard
@ 2022-02-14 19:26     ` Jernej Škrabec
  2022-02-15 14:37       ` John Cox
  0 siblings, 1 reply; 8+ messages in thread
From: Jernej Škrabec @ 2022-02-14 19:26 UTC (permalink / raw)
  To: mchehab, ezequiel, p.zabel, gregkh, mripard, paul.kocialkowski,
	wens, hverkuil-cisco, jonas, nicolas, Benjamin Gaignard
  Cc: linux-media, linux-kernel, linux-staging, linux-arm-kernel,
	linux-sunxi, kernel, Alex Bee, jc

Dne ponedeljek, 14. februar 2022 ob 18:25:01 CET je Benjamin Gaignard 
napisal(a):
> 
> Le 13/02/2022 à 12:33, Jernej Škrabec a écrit :
> > Hi Benjamin,
> >
> > CC: Alex, John
> >
> > Sorry for late response, but I've been very busy last week.
> >
> > First of all, thank you for doing this! It's about time that HEVC moves
> > forward.
> >
> > Dne torek, 01. februar 2022 ob 13:34:39 CET je Benjamin Gaignard 
napisal(a):
> >> The HEVC stateless 'uAPI' was staging and marked explicitly in the
> >> V4L2 specification that it will change and is unstable.
> >>
> >> Note that these control IDs were never exported as a public API,
> >> they were only defined in kernel-local headers (hevc-ctrls.h).
> >>
> >> While moving the controls out of staging they are renamed and
> >> control IDs get new numbers.
> >> Drivers (Hantro, Cedrus) and Documentation are updated accordaly.
> > accordaly -> accordingly
> >
> >> Additional structures fields has been added for RKVDEC driver usage.
> > You should do separate patch for that, preceding this one. One patch 
should
> > only do one thing.
> 
> I will do that in v2
> 
> >
> > I also suggest that you add additional patch for removing bit_size field in
> > struct v4l2_ctrl_hevc_slice_params. Similar fields were already removed 
from
> > MPEG2 and H264 structures. Bit size can be deduced from output buffer size 
and
> > it doesn't hurt if bit size in Cedrus is set to bigger value than actual 
slice
> > bit size.
> 
> ok
> 
> >
> >> Hantro dedicated control is moving to hantro-media.h
> >> Since hevc-ctrls.h content has been dispatched in others file, remove it.
> >>
> >> fluster tests results on IMX8MQ is 77/147 for HEVC codec.
> >>
> >> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
> > Note that Cedrus still needs additional information in order to decode 
some
> > HEVC videos. Missing info is num_entry_point_offsets and list of all
> > entry_point_offset_minus1 (obviously, num_entry_point_offsets in size).
> >
> > I suggest that this is represented in a new control, which would use 
dynamic
> > array feature, written by Hans. While Cedrus supports max. 256 entries, it 
can
> > be much bigger in theory, but in reality, it's much smaller (like 4-8
> > entries).
> 
> I haven't seen yet any user for these fields but I will create a new control 
like
> #define V4L2_CID_STATELESS_HEVC_ENTRY_POINT	(V4L2_CID_CODEC_STATELESS_BASE + 
407)
> 
> struct v4l2_ctrl_hevc_entry_point_offset {
> 	__u32	entry_point_offset_minus1;
> };

Yeah, Cedrus is currently the only mainline driver that needs that in order to 
fully work. I think John used num_entry_point_offsets in his (out of tree) RPi 
HEVC decoding driver too.

Wouldn't be easier to just use u32 directly? This is just array of numbers, so 
nothing else will be added in that struct...

Anyway, once you add this, I'll quickly update driver to take advantage of it.

> 
> and add it in the documentation:
> ``V4L2_CID_STATELESS_HEVC_ENTRY_POINT (struct)``
>      Specifies the i-th entry point offset in bytes and is represented by
>      offset_len_minus1 plus 1 bits.
>      This control is a dynamically sized array. The number of entry point
>      offsets is reported by the ``elems`` field.
>      This bitstream parameter is defined according to :ref:`hevc`.
>      They are described in section 7.4.7.1 "General slice segment header
>      semantics" of the specification.
> 
> >
> > Last but not least, data_bit_offset should be better defined. Currently it
> > points right after last header bit, just like Cedrus needs it. However, 
there
> > is padding after that, at least 1 bit and 8 bits at most, so slice data 
always
> > starts from byte aligned address. It probably make sense to rework that 
field
> > to be byte offset, not bit, just like in VA-API. Note that RPi HEVC driver 
also
> > uses byte aligned address directly. Cedrus would need some kind of 
workaround
> > and only one that works is this one:
> > https://github.com/bootlin/libva-v4l2-request/blob/master/src/h265.c#L191-L209
> 
> If Cedrus driver is happy with this definition I will keep it like that.
> When providing offset in bit is more accurate and any driver can align the 
value
> if needed, the reverse (byte -> bit) isn't possible.

If I'm not mistaken, HEVC standard actually requires that slice data starts at 
byte aligned address, so nothing would be lost for correctness of uAPI.

I already had this discussion with John and IIRC conclusion was to have byte 
aligned value here. John, can you please confirm if my interpretation is 
correct?

Best regards,
Jernej

> 
> Regards,
> Benjamin
> 
> >
> > Best regards,
> > Jernej
> >
> >
> 



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC] media: uapi: Move HEVC stateless controls out of staging
  2022-02-14 19:26     ` Jernej Škrabec
@ 2022-02-15 14:37       ` John Cox
  2022-02-15 14:51         ` Benjamin Gaignard
  0 siblings, 1 reply; 8+ messages in thread
From: John Cox @ 2022-02-15 14:37 UTC (permalink / raw)
  To: Jernej Škrabec
  Cc: mchehab, ezequiel, p.zabel, gregkh, mripard, paul.kocialkowski,
	wens, hverkuil-cisco, jonas, nicolas, Benjamin Gaignard,
	linux-media, linux-kernel, linux-staging, linux-arm-kernel,
	linux-sunxi, kernel, Alex Bee

On Mon, 14 Feb 2022 20:26:34 +0100, you wrote:

>Dne ponedeljek, 14. februar 2022 ob 18:25:01 CET je Benjamin Gaignard 
>napisal(a):
>> 
>> Le 13/02/2022 à 12:33, Jernej Škrabec a écrit :
>> > Hi Benjamin,
>> >
>> > CC: Alex, John
>> >
>> > Sorry for late response, but I've been very busy last week.
>> >
>> > First of all, thank you for doing this! It's about time that HEVC moves
>> > forward.
>> >
>> > Dne torek, 01. februar 2022 ob 13:34:39 CET je Benjamin Gaignard 
>napisal(a):
>> >> The HEVC stateless 'uAPI' was staging and marked explicitly in the
>> >> V4L2 specification that it will change and is unstable.
>> >>
>> >> Note that these control IDs were never exported as a public API,
>> >> they were only defined in kernel-local headers (hevc-ctrls.h).
>> >>
>> >> While moving the controls out of staging they are renamed and
>> >> control IDs get new numbers.
>> >> Drivers (Hantro, Cedrus) and Documentation are updated accordaly.
>> > accordaly -> accordingly
>> >
>> >> Additional structures fields has been added for RKVDEC driver usage.
>> > You should do separate patch for that, preceding this one. One patch 
>should
>> > only do one thing.
>> 
>> I will do that in v2
>> 
>> >
>> > I also suggest that you add additional patch for removing bit_size field in
>> > struct v4l2_ctrl_hevc_slice_params. Similar fields were already removed 
>from
>> > MPEG2 and H264 structures. Bit size can be deduced from output buffer size 
>and
>> > it doesn't hurt if bit size in Cedrus is set to bigger value than actual 
>slice
>> > bit size.
>> 
>> ok
>> 
>> >
>> >> Hantro dedicated control is moving to hantro-media.h
>> >> Since hevc-ctrls.h content has been dispatched in others file, remove it.
>> >>
>> >> fluster tests results on IMX8MQ is 77/147 for HEVC codec.
>> >>
>> >> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
>> > Note that Cedrus still needs additional information in order to decode 
>some
>> > HEVC videos. Missing info is num_entry_point_offsets and list of all
>> > entry_point_offset_minus1 (obviously, num_entry_point_offsets in size).
>> >
>> > I suggest that this is represented in a new control, which would use 
>dynamic
>> > array feature, written by Hans. While Cedrus supports max. 256 entries, it 
>can
>> > be much bigger in theory, but in reality, it's much smaller (like 4-8
>> > entries).
>> 
>> I haven't seen yet any user for these fields but I will create a new control 
>like
>> #define V4L2_CID_STATELESS_HEVC_ENTRY_POINT	(V4L2_CID_CODEC_STATELESS_BASE + 
>407)
>> 
>> struct v4l2_ctrl_hevc_entry_point_offset {
>> 	__u32	entry_point_offset_minus1;
>> };

Can we tell if this control is needed from userland? There's no great
point in filling it in if the driver isn't going to use it.

>Yeah, Cedrus is currently the only mainline driver that needs that in order to 
>fully work. I think John used num_entry_point_offsets in his (out of tree) RPi 
>HEVC decoding driver too.

num_entry_points is a useful field  (in the slice header preferably) for
the RPi hardware as whilst it doesn't need to know the offsets it does
need to construct a table with one entry per offset (for cabac state
purposes) so it needs to know how many there are. It is possible to
infer the number from the slice_segment address in the next slice header
but that involves keeping around more state from one request to the
next.

>Wouldn't be easier to just use u32 directly? This is just array of numbers, so 
>nothing else will be added in that struct...
>
>Anyway, once you add this, I'll quickly update driver to take advantage of it.
>
>> 
>> and add it in the documentation:
>> ``V4L2_CID_STATELESS_HEVC_ENTRY_POINT (struct)``
>>      Specifies the i-th entry point offset in bytes and is represented by
>>      offset_len_minus1 plus 1 bits.
>>      This control is a dynamically sized array. The number of entry point
>>      offsets is reported by the ``elems`` field.
>>      This bitstream parameter is defined according to :ref:`hevc`.
>>      They are described in section 7.4.7.1 "General slice segment header
>>      semantics" of the specification.
>> 
>> >
>> > Last but not least, data_bit_offset should be better defined. Currently it
>> > points right after last header bit, just like Cedrus needs it. However, 
>there
>> > is padding after that, at least 1 bit and 8 bits at most, so slice data 
>always
>> > starts from byte aligned address. It probably make sense to rework that 
>field
>> > to be byte offset, not bit, just like in VA-API. Note that RPi HEVC driver 
>also
>> > uses byte aligned address directly. Cedrus would need some kind of 
>workaround
>> > and only one that works is this one:
>> > https://github.com/bootlin/libva-v4l2-request/blob/master/src/h265.c#L191-L209
>> 
>> If Cedrus driver is happy with this definition I will keep it like that.
>> When providing offset in bit is more accurate and any driver can align the 
>value
>> if needed, the reverse (byte -> bit) isn't possible.
>
>If I'm not mistaken, HEVC standard actually requires that slice data starts at 
>byte aligned address, so nothing would be lost for correctness of uAPI.
>
>I already had this discussion with John and IIRC conclusion was to have byte 
>aligned value here. John, can you please confirm if my interpretation is 
>correct?

Yes slice_segment_data only occurs afer slice_segment_header (7.3.6.1)
and that ends with byte_alignment().

Regards

John Cox

>Best regards,
>Jernej
>
>> 
>> Regards,
>> Benjamin
>> 
>> >
>> > Best regards,
>> > Jernej
>> >
>> >
>> 
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC] media: uapi: Move HEVC stateless controls out of staging
  2022-02-15 14:37       ` John Cox
@ 2022-02-15 14:51         ` Benjamin Gaignard
  0 siblings, 0 replies; 8+ messages in thread
From: Benjamin Gaignard @ 2022-02-15 14:51 UTC (permalink / raw)
  To: John Cox, Jernej Škrabec
  Cc: mchehab, ezequiel, p.zabel, gregkh, mripard, paul.kocialkowski,
	wens, hverkuil-cisco, jonas, nicolas, linux-media, linux-kernel,
	linux-staging, linux-arm-kernel, linux-sunxi, kernel, Alex Bee


Le 15/02/2022 à 15:37, John Cox a écrit :
> On Mon, 14 Feb 2022 20:26:34 +0100, you wrote:
>
>> Dne ponedeljek, 14. februar 2022 ob 18:25:01 CET je Benjamin Gaignard
>> napisal(a):
>>> Le 13/02/2022 à 12:33, Jernej Škrabec a écrit :
>>>> Hi Benjamin,
>>>>
>>>> CC: Alex, John
>>>>
>>>> Sorry for late response, but I've been very busy last week.
>>>>
>>>> First of all, thank you for doing this! It's about time that HEVC moves
>>>> forward.
>>>>
>>>> Dne torek, 01. februar 2022 ob 13:34:39 CET je Benjamin Gaignard
>> napisal(a):
>>>>> The HEVC stateless 'uAPI' was staging and marked explicitly in the
>>>>> V4L2 specification that it will change and is unstable.
>>>>>
>>>>> Note that these control IDs were never exported as a public API,
>>>>> they were only defined in kernel-local headers (hevc-ctrls.h).
>>>>>
>>>>> While moving the controls out of staging they are renamed and
>>>>> control IDs get new numbers.
>>>>> Drivers (Hantro, Cedrus) and Documentation are updated accordaly.
>>>> accordaly -> accordingly
>>>>
>>>>> Additional structures fields has been added for RKVDEC driver usage.
>>>> You should do separate patch for that, preceding this one. One patch
>> should
>>>> only do one thing.
>>> I will do that in v2
>>>
>>>> I also suggest that you add additional patch for removing bit_size field in
>>>> struct v4l2_ctrl_hevc_slice_params. Similar fields were already removed
>> from
>>>> MPEG2 and H264 structures. Bit size can be deduced from output buffer size
>> and
>>>> it doesn't hurt if bit size in Cedrus is set to bigger value than actual
>> slice
>>>> bit size.
>>> ok
>>>
>>>>> Hantro dedicated control is moving to hantro-media.h
>>>>> Since hevc-ctrls.h content has been dispatched in others file, remove it.
>>>>>
>>>>> fluster tests results on IMX8MQ is 77/147 for HEVC codec.
>>>>>
>>>>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
>>>> Note that Cedrus still needs additional information in order to decode
>> some
>>>> HEVC videos. Missing info is num_entry_point_offsets and list of all
>>>> entry_point_offset_minus1 (obviously, num_entry_point_offsets in size).
>>>>
>>>> I suggest that this is represented in a new control, which would use
>> dynamic
>>>> array feature, written by Hans. While Cedrus supports max. 256 entries, it
>> can
>>>> be much bigger in theory, but in reality, it's much smaller (like 4-8
>>>> entries).
>>> I haven't seen yet any user for these fields but I will create a new control
>> like
>>> #define V4L2_CID_STATELESS_HEVC_ENTRY_POINT	(V4L2_CID_CODEC_STATELESS_BASE +
>> 407)
>>> struct v4l2_ctrl_hevc_entry_point_offset {
>>> 	__u32	entry_point_offset_minus1;
>>> };
> Can we tell if this control is needed from userland? There's no great
> point in filling it in if the driver isn't going to use it.
>
>> Yeah, Cedrus is currently the only mainline driver that needs that in order to
>> fully work. I think John used num_entry_point_offsets in his (out of tree) RPi
>> HEVC decoding driver too.
> num_entry_points is a useful field  (in the slice header preferably) for
> the RPi hardware as whilst it doesn't need to know the offsets it does
> need to construct a table with one entry per offset (for cabac state
> purposes) so it needs to know how many there are. It is possible to
> infer the number from the slice_segment address in the next slice header
> but that involves keeping around more state from one request to the
> next.

In v2 I have remove the structure and only keep a dynamic v4l2 control (an array
of integer). Control num_elems could be used as num_entry_points field.
Userland can test if the driver implement the control to decide to fill or not.
It is already the case in GStreamer for Hantro dedicate control.

>
>> Wouldn't be easier to just use u32 directly? This is just array of numbers, so
>> nothing else will be added in that struct...
>>
>> Anyway, once you add this, I'll quickly update driver to take advantage of it.
>>
>>> and add it in the documentation:
>>> ``V4L2_CID_STATELESS_HEVC_ENTRY_POINT (struct)``
>>>       Specifies the i-th entry point offset in bytes and is represented by
>>>       offset_len_minus1 plus 1 bits.
>>>       This control is a dynamically sized array. The number of entry point
>>>       offsets is reported by the ``elems`` field.
>>>       This bitstream parameter is defined according to :ref:`hevc`.
>>>       They are described in section 7.4.7.1 "General slice segment header
>>>       semantics" of the specification.
>>>
>>>> Last but not least, data_bit_offset should be better defined. Currently it
>>>> points right after last header bit, just like Cedrus needs it. However,
>> there
>>>> is padding after that, at least 1 bit and 8 bits at most, so slice data
>> always
>>>> starts from byte aligned address. It probably make sense to rework that
>> field
>>>> to be byte offset, not bit, just like in VA-API. Note that RPi HEVC driver
>> also
>>>> uses byte aligned address directly. Cedrus would need some kind of
>> workaround
>>>> and only one that works is this one:
>>>> https://github.com/bootlin/libva-v4l2-request/blob/master/src/h265.c#L191-L209
>>> If Cedrus driver is happy with this definition I will keep it like that.
>>> When providing offset in bit is more accurate and any driver can align the
>> value
>>> if needed, the reverse (byte -> bit) isn't possible.
>> If I'm not mistaken, HEVC standard actually requires that slice data starts at
>> byte aligned address, so nothing would be lost for correctness of uAPI.
>>
>> I already had this discussion with John and IIRC conclusion was to have byte
>> aligned value here. John, can you please confirm if my interpretation is
>> correct?
> Yes slice_segment_data only occurs afer slice_segment_header (7.3.6.1)
> and that ends with byte_alignment().

I have done a patch for that change in v2.

Regards,

Benjamin

>
> Regards
>
> John Cox
>
>> Best regards,
>> Jernej
>>
>>> Regards,
>>> Benjamin
>>>
>>>> Best regards,
>>>> Jernej
>>>>
>>>>

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2022-02-15 14:52 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-01 12:34 [RFC] media: uapi: Move HEVC stateless controls out of staging Benjamin Gaignard
2022-02-13 11:33 ` Jernej Škrabec
2022-02-14 10:01   ` Hans Verkuil
2022-02-14 17:26     ` Benjamin Gaignard
2022-02-14 17:25   ` Benjamin Gaignard
2022-02-14 19:26     ` Jernej Škrabec
2022-02-15 14:37       ` John Cox
2022-02-15 14:51         ` Benjamin Gaignard

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).