Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp4414099pxa; Mon, 10 Aug 2020 08:32:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzmcPyHAmmJWui9imBtzU7nWpHqEUiGgf+04K8wIXaOt0y8T9r1bkjGSchdJWrQ0sTLhcBM X-Received: by 2002:a17:906:3b8d:: with SMTP id u13mr21708831ejf.383.1597073528545; Mon, 10 Aug 2020 08:32:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597073528; cv=none; d=google.com; s=arc-20160816; b=jH5q8CIPvAVRAe4tQOv7Y11Z8MmADNjciHF9UQS1ca8FdWA9Lfw/q7ZfZRMRvc+yqm WtJ8Bt1JWhD9YTAPNnaDP1bwmB/17Oe4Zr6uPlgzxDe3Yd3OD/VsHnCOw1iAnDiCZQcv /4cVoYkwwH4+/CT+wSyt40ftBwMQyckv5JD5H2MbTsRq5SoUrS4S3ID7rsJ7zifVMub0 u6UW99zqu6DQkJ2Awa4eTvuod4up8BIPud6cuvYnP6Ku6PEvMer3MhLen4DmxZJAMX6K yFap9zq8HEk3Xyubvmmxu6rxD/TRa7q3q3ML0Rnv1gaV7Yf+ZRLJgysVLAA/ido1j9y+ 7ttg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:organization:references:in-reply-to:date:cc:to:from :subject:message-id; bh=BedmoViCz46k/yPDJpY1ifdzYEDC2JK4+7fIYXCJ5Qo=; b=XEysF/X8twElwrHHB51gRY0Lq6AqapA6xoDY6YzKFeHwxEhZHhAFh8Gz2BG8RTyBZZ JQtUU4YuqxwdRjgAo1F4yNQhMmh+pye9GJKNCBtXXmgfOWKD/I/aPXDNgbvbl5v3T2UV +sw11+gFpTBxB+eeuk9pazJ6/JSoJqe6wIgDQz5tINvoQ8W/W/kxqDs6xfx4KZzoioc8 CJJ/uqKIldTqkvcknCLGPUMLgqoexsFZ3xLPUM0Bqp8iswRLxr28UNI9q15Ub7611IEP prvkhQYPmAv+e4AwgVKu9oBHk2hyfpximwW+d4xCcHjP2HkuYo6xt3zDhyzzL72PQcQy lB2w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f25si10937413eje.338.2020.08.10.08.31.45; Mon, 10 Aug 2020 08:32:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728681AbgHJP3R (ORCPT + 99 others); Mon, 10 Aug 2020 11:29:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36356 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728049AbgHJP3M (ORCPT ); Mon, 10 Aug 2020 11:29:12 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 07D7EC061756; Mon, 10 Aug 2020 08:29:12 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: ezequiel) with ESMTPSA id 0670D26B015 Message-ID: Subject: Re: [PATCH v2 03/14] media: uapi: h264: Split prediction weight parameters From: Ezequiel Garcia To: Jonas Karlman , Jernej =?UTF-8?Q?=C5=A0krabec?= Cc: linux-media , Linux Kernel Mailing List , Tomasz Figa , kernel@collabora.com, Hans Verkuil , Alexandre Courbot , Jeffrey Kardatzke , Nicolas Dufresne , Philipp Zabel , Maxime Ripard , Paul Kocialkowski Date: Mon, 10 Aug 2020 12:28:59 -0300 In-Reply-To: References: <20200806151310.98624-1-ezequiel@collabora.com> <2380739.qXQpHEDp1t@jernej-laptop> <8cf55169fa1dd55b5bdf746b321419f8c7988821.camel@collabora.com> Organization: Collabora Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2020-08-10 at 14:55 +0000, Jonas Karlman wrote: > On 2020-08-10 14:57, Ezequiel Garcia wrote: > > On Sun, 2020-08-09 at 23:11 +0200, Jernej Škrabec wrote: > > > Dne nedelja, 09. avgust 2020 ob 15:55:50 CEST je Ezequiel Garcia napisal(a): > > > > On Sat, 8 Aug 2020 at 18:01, Jonas Karlman wrote: > > > > > On 2020-08-06 17:12, Ezequiel Garcia wrote: > > > > > > The prediction weight parameters are only required under > > > > > > certain conditions, which depend on slice header parameters. > > > > > > > > > > > > As specified in section 7.3.3 Slice header syntax, the prediction > > > > > > weight table is present if: > > > > > > > > > > > > ((weighted_pred_flag && (slice_type == P || slice_type == SP)) || \ > > > > > > (weighted_bipred_idc == 1 && slice_type == B)) > > > > > > > > > > Maybe a macro can be added to help check this contition? > > > > > > > > > > Something like this maybe: > > > > > > > > > > #define V4L2_H264_CTRL_PRED_WEIGHTS_REQUIRED(pps, slice) \ > > > > > > > > > > ((((pps)->flags & V4L2_H264_PPS_FLAG_WEIGHTED_PRED) && \ > > > > > > > > > > ((slice)->slice_type == V4L2_H264_SLICE_TYPE_P || \ > > > > > > > > > > (slice)->slice_type == V4L2_H264_SLICE_TYPE_SP)) || \ > > > > > > > > > > ((pps)->weighted_bipred_idc == 1 && \ > > > > > > > > > > (slice)->slice_type == V4L2_H264_SLICE_TYPE_B)) > > > > > > > > Yeah, that could make sense. > > > > > > > > Note that the biggest value in having the prediction weight table > > > > separated is to allow applications to skip setting this largish control, > > > > reducing the amount of data that needs to be passed from userspace > > > > -- especially when not needed :-) > > > > > > > > > > Given its size, it makes sense to move this table to its control, > > > > > > so applications can avoid passing it if the slice doesn't specify it. > > > > > > > > > > > > Before this change struct v4l2_ctrl_h264_slice_params was 960 bytes. > > > > > > With this change, it's 188 bytes and struct v4l2_ctrl_h264_pred_weight > > > > > > is 772 bytes. > > > > > > > > > > > > Signed-off-by: Ezequiel Garcia > > > > > > --- > > > > > > v2: Fix missing Cedrus changes and mssing control declaration, > > > > > > > > > > > > as noted by Hans and Jernej. > > > > > > > > > > > > --- > > > > > > > > > > > > .../media/v4l/ext-ctrls-codec.rst | 19 ++++++++++++------- > > > > > > drivers/media/v4l2-core/v4l2-ctrls.c | 8 ++++++++ > > > > > > drivers/staging/media/sunxi/cedrus/cedrus.c | 7 +++++++ > > > > > > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 + > > > > > > .../staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++ > > > > > > .../staging/media/sunxi/cedrus/cedrus_h264.c | 6 ++---- > > > > > > include/media/h264-ctrls.h | 5 +++-- > > > > > > include/media/v4l2-ctrls.h | 2 ++ > > > > > > 8 files changed, 37 insertions(+), 13 deletions(-) > > > > > > > > > > > > diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > > > > b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index > > > > > > d1438b1e259f..c36ce5a95fc5 100644 > > > > > > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > > > > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > > > > @@ -1879,18 +1879,23 @@ enum > > > > > > v4l2_mpeg_video_h264_hierarchical_coding_type -> > > > > > > > - 0x00000008 > > > > > > - > > > > > > > > > > > > -``Prediction Weight Table`` > > > > > > +``V4L2_CID_MPEG_VIDEO_H264_PRED_WEIGHTS (struct)`` > > > > > > + Prediction weight table defined according to :ref:`h264`, > > > > > > + section 7.4.3.2 "Prediction Weight Table Semantics". > > > > > > + The prediction weight table must be passed by applications > > > > > > + under the conditions explained in section 7.3.3 "Slice header > > > > > > + syntax". > > > > > > > > > > > > - The bitstream parameters are defined according to :ref:`h264`, > > > > > > - section 7.4.3.2 "Prediction Weight Table Semantics". For further > > > > > > - documentation, refer to the above specification, unless there is > > > > > > - an explicit comment stating otherwise. > > > > > > + .. note:: > > > > > > + > > > > > > + This compound control is not yet part of the public kernel API > > > > > > and > > > > > > + it is expected to change. > > > > > > > > > > > > -.. c:type:: v4l2_h264_pred_weight_table > > > > > > +.. c:type:: v4l2_ctrl_h264_pred_weights > > > > > > > > > > > > .. cssclass:: longtable > > > > > > > > > > > > -.. flat-table:: struct v4l2_h264_pred_weight_table > > > > > > +.. flat-table:: struct v4l2_ctrl_h264_pred_weights > > > > > > > > > > > > :header-rows: 0 > > > > > > :stub-columns: 0 > > > > > > :widths: 1 1 2 > > > > > > > > > > > > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c > > > > > > b/drivers/media/v4l2-core/v4l2-ctrls.c index 3f3fbcd60cc6..76c8dc8fb31c > > > > > > 100644 > > > > > > --- a/drivers/media/v4l2-core/v4l2-ctrls.c > > > > > > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c > > > > > > @@ -897,6 +897,7 @@ const char *v4l2_ctrl_get_name(u32 id) > > > > > > > > > > > > case V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS: return > > > > > > "H264 Decode Parameters"; case > > > > > > V4L2_CID_MPEG_VIDEO_H264_DECODE_MODE: return "H264 > > > > > > Decode Mode"; case V4L2_CID_MPEG_VIDEO_H264_START_CODE: > > > > > > return "H264 Start Code";> > > > > > > > + case V4L2_CID_MPEG_VIDEO_H264_PRED_WEIGHTS: return > > > > > > "H264 Prediction Weight Table";> > > > > > > > case V4L2_CID_MPEG_VIDEO_MPEG2_LEVEL: return > > > > > > "MPEG2 Level"; case V4L2_CID_MPEG_VIDEO_MPEG2_PROFILE: > > > > > > return "MPEG2 Profile"; case > > > > > > V4L2_CID_MPEG_VIDEO_MPEG4_I_FRAME_QP: return "MPEG4 > > > > > > I-Frame QP Value";> > > > > > > > @@ -1412,6 +1413,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, > > > > > > enum v4l2_ctrl_type *type,> > > > > > > > case V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS: > > > > > > *type = V4L2_CTRL_TYPE_H264_DECODE_PARAMS; > > > > > > break; > > > > > > > > > > > > + case V4L2_CID_MPEG_VIDEO_H264_PRED_WEIGHTS: > > > > > > + *type = V4L2_CTRL_TYPE_H264_PRED_WEIGHTS; > > > > > > + break; > > > > > > > > > > > > case V4L2_CID_MPEG_VIDEO_VP8_FRAME_HEADER: > > > > > > *type = V4L2_CTRL_TYPE_VP8_FRAME_HEADER; > > > > > > break; > > > > > > > > > > > > @@ -1790,6 +1794,7 @@ static int std_validate_compound(const struct > > > > > > v4l2_ctrl *ctrl, u32 idx,> > > > > > > > case V4L2_CTRL_TYPE_H264_SPS: > > > > > > case V4L2_CTRL_TYPE_H264_PPS: > > > > > > > > > > > > case V4L2_CTRL_TYPE_H264_SCALING_MATRIX: > > > > > > + case V4L2_CTRL_TYPE_H264_PRED_WEIGHTS: > > > > > > case V4L2_CTRL_TYPE_H264_SLICE_PARAMS: > > > > > > > > > > > > case V4L2_CTRL_TYPE_H264_DECODE_PARAMS: > > > > > > break; > > > > > > > > > > > > @@ -2553,6 +2558,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct > > > > > > v4l2_ctrl_handler *hdl,> > > > > > > > case V4L2_CTRL_TYPE_H264_DECODE_PARAMS: > > > > > > elem_size = sizeof(struct v4l2_ctrl_h264_decode_params); > > > > > > break; > > > > > > > > > > > > + case V4L2_CTRL_TYPE_H264_PRED_WEIGHTS: > > > > > > + elem_size = sizeof(struct v4l2_ctrl_h264_pred_weights); > > > > > > + break; > > > > > > > > > > > > case V4L2_CTRL_TYPE_VP8_FRAME_HEADER: > > > > > > elem_size = sizeof(struct v4l2_ctrl_vp8_frame_header); > > > > > > break; > > > > > > > > > > > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c > > > > > > b/drivers/staging/media/sunxi/cedrus/cedrus.c index > > > > > > bc27f9430eeb..027cdd1be5a0 100644 > > > > > > --- a/drivers/staging/media/sunxi/cedrus/cedrus.c > > > > > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c > > > > > > @@ -78,6 +78,13 @@ static const struct cedrus_control cedrus_controls[] > > > > > > = { > > > > > > > > > > > > .codec = CEDRUS_CODEC_H264, > > > > > > .required = true, > > > > > > > > > > > > }, > > > > > > > > > > > > + { > > > > > > + .cfg = { > > > > > > + .id = V4L2_CID_MPEG_VIDEO_H264_PRED_WEIGHTS, > > > > > > + }, > > > > > > + .codec = CEDRUS_CODEC_H264, > > > > > > + .required = true, > > > > > > > > > > This should probably be false if this control is to be optional as implied > > > > > by the commit message. > > > > > > > > Well, the control is optional if the driver implements it as optional, > > > > which Cedrus isn't currently doing :-) > > > > > > Why do you think so? Prediction weights are filled only when they are > > > needed:https://elixir.bootlin.com/linux/latest/source/drivers/staging/media/ > > > sunxi/cedrus/cedrus_h264.c#L370 > > > > > > > Right, but that should be changed to be really optional. > > How does the driver reject/fail the request if the table is NULL? > > > > In any case, I don't think it's necessarily something we need > > to tackle now. > > I do not fully follow, the commit message state following: > > Note that the biggest value in having the prediction weight table > separated is to allow applications to skip setting this largish control > This is not exactly what the commit message says, but yeah that's the idea. > Yet the driver still require this new control to be included in the request > thanks to the .required = true statement. (if i understand the code correctly) > > So applications still need to set this largish control? > This is a uAPI change that paves the way for Cedrus to make the control optional. The series doesn't take care of it, but it prepares the road for it. Since we are not stabilizing the uAPI (yet), I think we still have some room to make this change in steps: first we merge the new control and then we add the needed changes to Cedrus? Does that make sense? > Best regards, > Jonas > > > Thanks, > > Ezequiel > >