Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1682012ybt; Thu, 25 Jun 2020 11:31:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxqZImD8Hqp+but39++jQnuA+eUpqlUZim6sdsYrIdhR6f6O0+8CUdqEVBfD6AdSccWHoco X-Received: by 2002:a50:f28e:: with SMTP id f14mr34683638edm.100.1593109887259; Thu, 25 Jun 2020 11:31:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593109887; cv=none; d=google.com; s=arc-20160816; b=xh4KdweLgn6Jnx6HNy2DJKrFQLYdcawClSVTRQ3E2orcgW59yVf3j9AxkhXG1oV9H2 5p/FCMxlt1bt7pO3cmwyKu/J4tWIrREcvBD6p3gTQbdu+lS3w964C7XvD8VyHh1PNmgA +ZaUuPsTIrqaGQj5iqVFQDHJw8ypDkKh2X978Kd51O/UxmsbGUXlW9Kmd2sRmkuq11H9 iUGMvkltGS/aRov8gOxuRrGWRqbeUnPw4P2pCzVabdyH/KuwYuecynnDARYuuFz0hxj1 Gsjhxt79cW1MtZO8UHc6ft6NXZsbgdq510hrQWnLX/0XDvAFhkrkeBgD037ibsLX8OjJ zLIA== 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=7eSVBnEbecZhcG7VvfFvVf9X3mA0bpgpBvC7xdtPfAE=; b=toEQj0qKQTpSAaHQxjW9sS6ciS6kZIXlJntPdywjm2m3HunPwAjqlgKB6Wruw7+Xs+ Y6BQ37X+C7WSPcJJq6sE/8npCIkIn7LYNN1wfCw4lAu+n3dkbkRzA/X3AdQoeOKL2J4M eFjqHgFzjO1f88EdCqMaMB994aUkzxAQxol1OxelDfGsmNGmPDmPuwg61g5xNgq/W3JE CPPu5MZgEvLeItOp7IUZJ2DYNQuvD84ToQfHyZRC8vWZVgi0qXgTquGzsoZAhsnbvnZt 4Rpi+Kjkklke5MHrbtBdlYuZScH++/EW6gpVJlVSdosZq3tDyLwOSiKC5ihvRvqpV9fX qHJg== 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 pj20si14722970ejb.158.2020.06.25.11.31.03; Thu, 25 Jun 2020 11:31:27 -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 S2406888AbgFYRn1 (ORCPT + 99 others); Thu, 25 Jun 2020 13:43:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2406882AbgFYRn0 (ORCPT ); Thu, 25 Jun 2020 13:43:26 -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 819B2C08C5C1; Thu, 25 Jun 2020 10:43:26 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: ezequiel) with ESMTPSA id 4C2FD2A576A Message-ID: Subject: Re: [RFC 2/7] fixup! media: uapi: h264: update reference lists From: Ezequiel Garcia To: Nicolas Dufresne , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, Jernej Skrabec Cc: Tomasz Figa , kernel@collabora.com, Jonas Karlman , Hans Verkuil , Alexandre Courbot , Jeffrey Kardatzke , Philipp Zabel , Maxime Ripard , Paul Kocialkowski Date: Thu, 25 Jun 2020 14:42:47 -0300 In-Reply-To: <27c646c790d6b00b29f4a61c58eb761ceb56179a.camel@collabora.com> References: <20200623182809.1375-1-ezequiel@collabora.com> <20200623182809.1375-3-ezequiel@collabora.com> <27c646c790d6b00b29f4a61c58eb761ceb56179a.camel@collabora.com> Organization: Collabora Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.0-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 (Adding Jernej, seems I haven't Cced him!) On Thu, 2020-06-25 at 10:53 -0400, Nicolas Dufresne wrote: > Le mardi 23 juin 2020 à 15:28 -0300, Ezequiel Garcia a écrit : > > Align v4l2_h264_reference to 32-bits, giving some room > > for future extensions. > > > > Signed-off-by: Ezequiel Garcia > > --- > > .../userspace-api/media/v4l/ext-ctrls-codec.rst | 3 +++ > > drivers/media/v4l2-core/v4l2-ctrls.c | 16 ++++++++++++++++ > > include/media/h264-ctrls.h | 7 +++++-- > > 3 files changed, 24 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > index 6c36d298db20..7af12447a5b0 100644 > > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > @@ -1943,6 +1943,9 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - > > * - __u8 > > - ``index`` > > - > > + * - __u32 > > + - ``reserved`` > > + - Applications and drivers must set this to zero. > > Is that really appropriate ? There was some effort to keep the controls > small. Also, as these are fixed size, they could be extended with > supplementary C arrays of the same size, set in separate control. > That's a very valid concern. Currently, each of these v4l2_h264_reference take 64 bytes (32 x 2 bytes). So it's 128 bytes of references. Having the reserved field means 256 bytes instead. Without the reserved field v4l2_ctrl_h264_slice_params is 936 bytes, the majority of the space taken by v4l2_h264_weight_factors. So, the reserved field accounts for a small increment there. Another option would be to split the v4l2_h264_reference lists to its own control. However, given the above, it would have more impact to consider splitting v4l2_h264_pred_weight_table. This table being used or not depends on the bitstream, so there might be some value here. What do you think? > Also, H264 HW is unlikely to evolve, and that covers what DXVA2 and > VAAPI covers already. So it is quite unlikely to ever have to be > extended. > That may be true indeed. Perhaps we can then agree that references only need an index and a flag. Thanks! Ezequiel > > > > .. _h264_reference_flags: > > > > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c > > index 3f3fbcd60cc6..6abd023f10c7 100644 > > --- a/drivers/media/v4l2-core/v4l2-ctrls.c > > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c > > @@ -1721,6 +1721,8 @@ static void std_log(const struct v4l2_ctrl *ctrl) > > > > #define zero_padding(s) \ > > memset(&(s).padding, 0, sizeof((s).padding)) > > +#define zero_reserved(s) \ > > + memset(&(s).reserved, 0, sizeof((s).reserved)) > > > > /* > > * Compound controls validation requires setting unused fields/flags to zero > > @@ -1731,6 +1733,7 @@ static int std_validate_compound(const struct v4l2_ctrl *ctrl, u32 idx, > > { > > struct v4l2_ctrl_mpeg2_slice_params *p_mpeg2_slice_params; > > struct v4l2_ctrl_vp8_frame_header *p_vp8_frame_header; > > + struct v4l2_ctrl_h264_slice_params *p_h264_slice_params; > > struct v4l2_ctrl_hevc_sps *p_hevc_sps; > > struct v4l2_ctrl_hevc_pps *p_hevc_pps; > > struct v4l2_ctrl_hevc_slice_params *p_hevc_slice_params; > > @@ -1790,7 +1793,20 @@ 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: > > + break; > > case V4L2_CTRL_TYPE_H264_SLICE_PARAMS: > > + p_h264_slice_params = p; > > + > > + for (i = 0; i < V4L2_H264_REF_PIC_LIST_LEN; i++) { > > + struct v4l2_h264_reference *ref0 = > > + &p_h264_slice_params->ref_pic_list0[i]; > > + struct v4l2_h264_reference *ref1 = > > + &p_h264_slice_params->ref_pic_list1[i]; > > + > > + zero_reserved(*ref0); > > + zero_reserved(*ref1); > > + } > > + break; > > case V4L2_CTRL_TYPE_H264_DECODE_PARAMS: > > break; > > > > diff --git a/include/media/h264-ctrls.h b/include/media/h264-ctrls.h > > index 9b1cbc9bc38e..c6cbf178c1c9 100644 > > --- a/include/media/h264-ctrls.h > > +++ b/include/media/h264-ctrls.h > > @@ -19,6 +19,8 @@ > > */ > > #define V4L2_H264_NUM_DPB_ENTRIES 16 > > > > +#define V4L2_H264_REF_PIC_LIST_LEN 32 > > + > > /* Our pixel format isn't stable at the moment */ > > #define V4L2_PIX_FMT_H264_SLICE v4l2_fourcc('S', '2', '6', '4') /* H264 parsed slices */ > > > > @@ -146,6 +148,7 @@ struct v4l2_h264_pred_weight_table { > > struct v4l2_h264_reference { > > __u8 flags; > > __u8 index; > > + __u16 reserved; > > }; > > > > struct v4l2_ctrl_h264_slice_params { > > @@ -190,8 +193,8 @@ struct v4l2_ctrl_h264_slice_params { > > * Entries on each list are indices into > > * v4l2_ctrl_h264_decode_params.dpb[]. > > */ > > - struct v4l2_h264_reference ref_pic_list0[32]; > > - struct v4l2_h264_reference ref_pic_list1[32]; > > + struct v4l2_h264_reference ref_pic_list0[V4L2_H264_REF_PIC_LIST_LEN]; > > + struct v4l2_h264_reference ref_pic_list1[V4L2_H264_REF_PIC_LIST_LEN]; > > > > __u32 flags; > > };