From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B404C43381 for ; Tue, 5 Mar 2019 11:16:38 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4BEF72082C for ; Tue, 5 Mar 2019 11:16:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="NXg29fZb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4BEF72082C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bootlin.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=MpDjEWua4vI0Jp68AWs9+onJ7nqjYZarxZmbJeiKzo8=; b=NXg29fZbJBgHhVZPsoe1RPWYp VG+ErxVWyfeUzVMzvx1UgQ+OUrxd4L/kBfxf56bwOztUcbbR1nzuBMa9AqiTqAOONXqWZKtfh5MkG wkEw1MnM3b2moVyHqUn/QPafCp5pTBGOXL6BL+pfCw3vKDa0q00zXxmjn86P2BCsI3ntmow/LEPMA BJU63KqtzUvK60jXHkylGBubhYkcfvTXZ8FFyfpz4/iTGo+QXZPjgITrVMTo1eeXtYz7q5zJlqWDH JxT6l2rGZg4PyCEK5EK3C1SMFSRrDsHPmycxvqdyxoc0QkC9iyAcqs605VPOeOCleI23DSFht4tFt JIgtaM4fw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h183m-0004Gt-DY; Tue, 05 Mar 2019 11:16:34 +0000 Received: from relay2-d.mail.gandi.net ([217.70.183.194]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h183j-0004GU-1X for linux-arm-kernel@lists.infradead.org; Tue, 05 Mar 2019 11:16:33 +0000 X-Originating-IP: 90.88.147.150 Received: from localhost (aaubervilliers-681-1-27-150.w90-88.abo.wanadoo.fr [90.88.147.150]) (Authenticated sender: maxime.ripard@bootlin.com) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id DEFFD4000E; Tue, 5 Mar 2019 11:16:25 +0000 (UTC) Date: Tue, 5 Mar 2019 12:16:25 +0100 From: Maxime Ripard To: Tomasz Figa Subject: Re: [PATCH v4 1/2] media: uapi: Add H264 low-level decoder API compound controls. Message-ID: <20190305111625.or44y4k7or25v44s@flea> References: <9817c9875638ed2484d61e6e128e2551cf3bda4c.1550672228.git-series.maxime.ripard@bootlin.com> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20180716 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190305_031631_389037_97CB920B X-CRM114-Status: GOOD ( 26.78 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "list@263.net:IOMMU DRIVERS , Joerg Roedel , " , Thomas Petazzoni , Alexandre Courbot , Jonas Karlman , jenskuske@gmail.com, linux-sunxi@googlegroups.com, Linux Kernel Mailing List , Jernej Skrabec , Paul Kocialkowski , Chen-Yu Tsai , Hans Verkuil , Laurent Pinchart , Sakari Ailus , Guenter Roeck , Nicolas Dufresne , Ezequiel Garcia , Pawel Osciak , Linux Media Mailing List Content-Type: multipart/mixed; boundary="===============5750822946068947729==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============5750822946068947729== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uuwvzyhdb64wixaa" Content-Disposition: inline --uuwvzyhdb64wixaa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 22, 2019 at 04:46:17PM +0900, Tomasz Figa wrote: > Hi Maxime, >=20 > On Wed, Feb 20, 2019 at 11:17 PM Maxime Ripard > wrote: > > > > From: Pawel Osciak > > > > Stateless video codecs will require both the H264 metadata and slices in > > order to be able to decode frames. > > > > This introduces the definitions for a new pixel format for H264 slices = that > > have been parsed, as well as the structures used to pass the metadata f= rom > > the userspace to the kernel. > > > > Co-Developped-by: Maxime Ripard > > Signed-off-by: Pawel Osciak > > Signed-off-by: Guenter Roeck > > Signed-off-by: Maxime Ripard >=20 > Thanks for the patch. Some comments inline. >=20 > [snip] > > +``V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS (struct)`` > > + Specifies the slice parameters (as extracted from the bitstream) > > + for the associated H264 slice data. This includes the necessary > > + parameters for configuring a stateless hardware decoding pipeline > > + for H264. The bitstream parameters are defined according to > > + :ref:`h264`. Unless there's a specific comment, refer to the > > + specification for the documentation of these fields, section 7.4.3 > > + "Slice Header Semantics". >=20 > Note that this is expected to be an array, with entries for all the > slices included in the bitstream buffer. >=20 > > + > > + .. note:: > > + > > + This compound control is not yet part of the public kernel API = and > > + it is expected to change. > > + > > +.. c:type:: v4l2_ctrl_h264_slice_param > > + > > +.. cssclass:: longtable > > + > > +.. flat-table:: struct v4l2_ctrl_h264_slice_param > > + :header-rows: 0 > > + :stub-columns: 0 > > + :widths: 1 1 2 > > + > > + * - __u32 > > + - ``size`` > > + - > > + * - __u32 > > + - ``header_bit_size`` > > + - > > + * - __u16 > > + - ``first_mb_in_slice`` > > + - > > + * - __u8 > > + - ``slice_type`` > > + - > > + * - __u8 > > + - ``pic_parameter_set_id`` > > + - > > + * - __u8 > > + - ``colour_plane_id`` > > + - > > + * - __u8 > > + - ``redundant_pic_cnt`` > > + - > > + * - __u16 > > + - ``frame_num`` > > + - > > + * - __u16 > > + - ``idr_pic_id`` > > + - > > + * - __u16 > > + - ``pic_order_cnt_lsb`` > > + - > > + * - __s32 > > + - ``delta_pic_order_cnt_bottom`` > > + - > > + * - __s32 > > + - ``delta_pic_order_cnt0`` > > + - > > + * - __s32 > > + - ``delta_pic_order_cnt1`` > > + - > > + * - struct :c:type:`v4l2_h264_pred_weight_table` > > + - ``pred_weight_table`` > > + - > > + * - __u32 > > + - ``dec_ref_pic_marking_bit_size`` > > + - > > + * - __u32 > > + - ``pic_order_cnt_bit_size`` > > + - > > + * - __u8 > > + - ``cabac_init_idc`` > > + - > > + * - __s8 > > + - ``slice_qp_delta`` > > + - > > + * - __s8 > > + - ``slice_qs_delta`` > > + - > > + * - __u8 > > + - ``disable_deblocking_filter_idc`` > > + - > > + * - __s8 > > + - ``slice_alpha_c0_offset_div2`` > > + - > > + * - __s8 > > + - ``slice_beta_offset_div2`` > > + - > > + * - __u8 > > + - ``num_ref_idx_l0_active_minus1`` > > + - > > + * - __u8 > > + - ``num_ref_idx_l1_active_minus1`` > > + - > > + * - __u32 > > + - ``slice_group_change_cycle`` > > + - > > + * - __u8 > > + - ``ref_pic_list0[32]`` > > + - > > + * - __u8 > > + - ``ref_pic_list1[32]`` > > + - >=20 > Should we explicitly document that these are the lists after applying > the per-slice modifications, as opposed to the original order from > v4l2_ctrl_h264_decode_param? >=20 > [snip] > > + * .. _V4L2-PIX-FMT-H264-SLICE: > > + > > + - ``V4L2_PIX_FMT_H264_SLICE`` > > + - 'S264' > > + - H264 parsed slice data, as extracted from the H264 bitstream. > > + This format is adapted for stateless video decoders that > > + implement an H264 pipeline (using the :ref:`codec` and > > + :ref:`media-request-api`). Metadata associated with the frame > > + to decode are required to be passed through the > > + ``V4L2_CID_MPEG_VIDEO_H264_SPS``, > > + ``V4L2_CID_MPEG_VIDEO_H264_PPS``, > > + ``V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS`` and > > + ``V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS`` controls and > > + scaling matrices can optionally be specified through the > > + ``V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX`` control. See the > > + :ref:`associated Codec Control IDs `. > > + Exactly one output and one capture buffer must be provided for > > + use with this pixel format. The output buffer must contain the > > + appropriate number of macroblocks to decode a full > > + corresponding frame to the matching capture buffer. >=20 > What does it mean that a control can be optionally specified? A > control always has a value, so how do we decide that it was specified > or not? Should we have another control (or flag) that selects whether > to use the control? How is it better than just having the control > initialized with the default scaling matrix and always using it? Ok, I'll change it. > > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videod= ev2.h > > index 9a920f071ff9..6443ae53597f 100644 > > --- a/include/uapi/linux/videodev2.h > > +++ b/include/uapi/linux/videodev2.h > > @@ -653,6 +653,7 @@ struct v4l2_pix_format { > > #define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /* H264 = with start codes */ > > #define V4L2_PIX_FMT_H264_NO_SC v4l2_fourcc('A', 'V', 'C', '1') /* H26= 4 without start codes */ > > #define V4L2_PIX_FMT_H264_MVC v4l2_fourcc('M', '2', '6', '4') /* H264 = MVC */ > > +#define V4L2_PIX_FMT_H264_SLICE v4l2_fourcc('S', '2', '6', '4') /* H26= 4 parsed slices */ >=20 > Are we okay with adding here already, without going through staging first? This is what we did for MPEG-2 already (the format is public but the controls are not), so I'm not sure this is causing any issue. Thanks! Maxime --=20 Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com --uuwvzyhdb64wixaa Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXH5aiQAKCRDj7w1vZxhR xQaDAPwIoVWR1TeT+e5bf+LEb/U2rgJXDTwx9jFMhcytq2st5AEAmizIpWf0N2Yg FG30mptGQpK4Z+e3nj9EK8Z5VcL3Qwg= =mZv8 -----END PGP SIGNATURE----- --uuwvzyhdb64wixaa-- --===============5750822946068947729== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============5750822946068947729==--