Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp5757765ioo; Wed, 1 Jun 2022 11:57:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwEjH+3cZ3RoFhp8TwfHLGy+GJf/yrSQVxrcpwFMmY8ra2rh/7i2SPJW5KCH2CuEAN/JfsY X-Received: by 2002:a17:90b:17d0:b0:1e3:5324:c465 with SMTP id me16-20020a17090b17d000b001e35324c465mr866525pjb.34.1654109861953; Wed, 01 Jun 2022 11:57:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654109861; cv=none; d=google.com; s=arc-20160816; b=0OeSo7TlsVjKt57FB0i66QX7ZAcowxHXcXzEens+344FJo36MxZbDUbDDRkJaPP6+5 mnUL6h1/LUMyGfsElTcekDHQXa1MJy1XmvwEt5JBjVCyhuF7NKrh0vT0jamBFQR+nWoJ 9VAe/nmUYm9pJ5UJRRPpy6jN3BRLtT3fKmTXi0yWlwHQZOa0QrUs6+TWY6Se3o4uXrQ2 vNnp/eh9w/n3i98cOVBskhBsrl0sAdMYLEyeW1FP2tCY2fjBkG+ttQRWl5x9qV5+J3jP Cf5t+Ni49bagh4rV+JNNTXQ/hdtFFWLUSt9T1l6iOBaZOTs0aUown6AgT0fAMMTzxzl7 V1dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:references :cc:to:from:content-language:subject:user-agent:mime-version:date :message-id; bh=EDYOrPy/SDWkHB7mx3ffcU00lWJpZYi6hyh/lRuGjTc=; b=VBxoI7L+qCd4lba3nsK7D6I40rBJFykX8HYsu0QIK+3OFbgb8luKpYAvt+my4lMKdl 7TQZ+IaEjgyc/yqQDHWMJAZLvxrJ8GoGORNww6FhKU5t1uT/GGrUc6k5+mBORFQ5zgXM Tgp07axcDs5thCiZXhbwy+VIFudyZDj5Mg/m3UJawH8s7fBAfQ7GUuJ3ubPFz9TQXrUH 0++3rdHP2DK6Z05jGek5ie2RrjilCjjGu1oQo/9m16oyP7Gdb0RaHQKQNIQOfAzyYWWG xSBvszd1JB6eoQXcnDFewc2WPoARw1Ad9RrsypL8s/yIuxH8Qp9LIKt0lLbVlxAjYP/o 36LQ== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xs4all.nl Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id e3-20020a17090ac20300b001dc7b989160si2913409pjt.130.2022.06.01.11.57.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 11:57:41 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xs4all.nl Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D5102BDA32; Wed, 1 Jun 2022 11:44:55 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241782AbiE3Op1 (ORCPT + 99 others); Mon, 30 May 2022 10:45:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55746 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241519AbiE3OXR (ORCPT ); Mon, 30 May 2022 10:23:17 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67CCF129EE2; Mon, 30 May 2022 06:50:35 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C52A760EC3; Mon, 30 May 2022 13:50:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E60E8C3411C; Mon, 30 May 2022 13:49:59 +0000 (UTC) Message-ID: Date: Mon, 30 May 2022 15:49:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH v6 11/17] media: uapi: Add V4L2_CID_STATELESS_HEVC_ENTRY_POINT_OFFSETS control Content-Language: en-US From: Hans Verkuil To: =?UTF-8?Q?Jernej_=c5=a0krabec?= , mchehab@kernel.org, ezequiel@vanguardiasur.com.ar, p.zabel@pengutronix.de, gregkh@linuxfoundation.org, mripard@kernel.org, paul.kocialkowski@bootlin.com, wens@csie.org, samuel@sholland.org, nicolas.dufresne@collabora.com, andrzej.p@collabora.com, Benjamin Gaignard Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-staging@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, kernel@collabora.com References: <20220527143134.3360174-1-benjamin.gaignard@collabora.com> <20220527143134.3360174-12-benjamin.gaignard@collabora.com> <2102641.irdbgypaU6@kista> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30/05/2022 11:18, Hans Verkuil wrote: > On 29/05/2022 08:40, Jernej Škrabec wrote: >> Hi! >> >> This series looks very good and I plan to test it shortly on Cedrus, but I >> have one major concern below. >> >> Dne petek, 27. maj 2022 ob 16:31:28 CEST je Benjamin Gaignard napisal(a): >>> The number of 'entry point offset' can be very variable. >>> Instead of using a large static array define a v4l2 dynamic array >>> of U32 (V4L2_CTRL_TYPE_U32). >>> The number of entry point offsets is reported by the elems field >>> and in struct v4l2_ctrl_hevc_slice_params.num_entry_point_offsets >>> field. >> >> Slice control by itself is variable length array, so you would actually need >> 2D variable array for entry points which is not supported. However, easy >> workaround for that is to flatten 2D array to 1D and either have another slice >> control field which would tell first entry point index for convenience or let >> driver calculate it by adding up all num_entry_point_offsets of previous >> slices. >> >> Hans, what do you think? > > If I would support 2D variable array sizes, wouldn't that be more elegant? > > The current implementation doesn't support that, but as the commit log for > patch 1/17 says: > > "Currently dynamically sized arrays are limited to one dimensional arrays, > but that might change in the future if there is a need for it." > > Let me know if you agree, and I'll try to implement this. It's been a while > since I last looked at this, so I'm not sure how much work it is, but it is > probably worth a shot. Digging more into this made me realize that this doesn't actually help for this particular case. I would lean towards your second suggestion of adding up all num_entry_point_offsets of previous slices. Regards, Hans > > Regards, > > Hans > >> >> Note, it seems that H265 decoding on Cedrus still works without entry points, >> so this problem can be solved later. I'm not sure what we lose with that but >> it was suggested that this could influence speed or error resilience or both. >> However, I think we're close to solve it, so I'd like to do that now. >> >> Best regards, >> Jernej >> >>> >>> Signed-off-by: Benjamin Gaignard >>> --- >>> .../userspace-api/media/v4l/ext-ctrls-codec.rst | 11 +++++++++++ >>> drivers/media/v4l2-core/v4l2-ctrls-defs.c | 5 +++++ >>> include/media/hevc-ctrls.h | 5 ++++- >>> 3 files changed, 20 insertions(+), 1 deletion(-) >>> >>> diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/ >> Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst >>> index 0796b1563daa..05228e280f66 100644 >>> --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst >>> +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst >>> @@ -3010,6 +3010,9 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - >>> * - __u32 >>> - ``data_bit_offset`` >>> - Offset (in bits) to the video data in the current slice data. >>> + * - __u32 >>> + - ``num_entry_point_offsets`` >>> + - Specifies the number of entry point offset syntax elements in the >> slice header. >>> * - __u8 >>> - ``nal_unit_type`` >>> - Specifies the coding type of the slice (B, P or I). >>> @@ -3150,6 +3153,14 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - >>> >>> \normalsize >>> >>> +``V4L2_CID_STATELESS_HEVC_ENTRY_POINT_OFFSETS (integer)`` >>> + Specifies entry point offsets in bytes. >>> + 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. >>> + >>> ``V4L2_CID_STATELESS_HEVC_SCALING_MATRIX (struct)`` >>> Specifies the HEVC scaling matrix parameters used for the scaling >> process >>> for transform coefficients. >>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/media/v4l2- >> core/v4l2-ctrls-defs.c >>> index d594efbcbb93..e22921e7ea61 100644 >>> --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c >>> +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c >>> @@ -1188,6 +1188,7 @@ const char *v4l2_ctrl_get_name(u32 id) >>> 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"; >>> + case V4L2_CID_STATELESS_HEVC_ENTRY_POINT_OFFSETS: return >> "HEVC Entry Point Offsets"; >>> >>> /* Colorimetry controls */ >>> /* Keep the order of the 'case's the same as in v4l2-controls.h! >> */ >>> @@ -1518,6 +1519,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum >> v4l2_ctrl_type *type, >>> case V4L2_CID_STATELESS_HEVC_DECODE_PARAMS: >>> *type = V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS; >>> break; >>> + case V4L2_CID_STATELESS_HEVC_ENTRY_POINT_OFFSETS: >>> + *type = V4L2_CTRL_TYPE_U32; >>> + *flags |= V4L2_CTRL_FLAG_DYNAMIC_ARRAY; >>> + break; >>> case V4L2_CID_STATELESS_VP9_COMPRESSED_HDR: >>> *type = V4L2_CTRL_TYPE_VP9_COMPRESSED_HDR; >>> break; >>> diff --git a/include/media/hevc-ctrls.h b/include/media/hevc-ctrls.h >>> index a3c829ef531a..1319cb99ae3f 100644 >>> --- a/include/media/hevc-ctrls.h >>> +++ b/include/media/hevc-ctrls.h >>> @@ -20,6 +20,7 @@ >>> #define V4L2_CID_STATELESS_HEVC_DECODE_PARAMS (V4L2_CID_CODEC_BASE >> + 1012) >>> #define V4L2_CID_STATELESS_HEVC_DECODE_MODE (V4L2_CID_CODEC_BASE + 1015) >>> #define V4L2_CID_STATELESS_HEVC_START_CODE (V4L2_CID_CODEC_BASE + 1016) >>> +#define V4L2_CID_STATELESS_HEVC_ENTRY_POINT_OFFSETS (V4L2_CID_CODEC_BASE + >> 1017) >>> >>> /* enum v4l2_ctrl_type type values */ >>> #define V4L2_CTRL_TYPE_HEVC_SPS 0x0120 >>> @@ -318,6 +319,8 @@ struct v4l2_hevc_pred_weight_table { >>> * >>> * @bit_size: size (in bits) of the current slice data >>> * @data_bit_offset: offset (in bits) to the video data in the current slice >> data >>> + * @num_entry_point_offsets: specifies the number of entry point offset syntax >>> + * elements in the slice header. >>> * @nal_unit_type: specifies the coding type of the slice (B, P or I) >>> * @nuh_temporal_id_plus1: minus 1 specifies a temporal identifier for the >> NAL unit >>> * @slice_type: see V4L2_HEVC_SLICE_TYPE_{} >>> @@ -360,7 +363,7 @@ struct v4l2_hevc_pred_weight_table { >>> struct v4l2_ctrl_hevc_slice_params { >>> __u32 bit_size; >>> __u32 data_bit_offset; >>> - >>> + __u32 num_entry_point_offsets; >>> /* ISO/IEC 23008-2, ITU-T Rec. H.265: NAL unit header */ >>> __u8 nal_unit_type; >>> __u8 nuh_temporal_id_plus1; >>> -- >>> 2.32.0 >>> >>> >> >> >