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=-3.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,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 352B5C4360F for ; Fri, 5 Apr 2019 15:16:06 +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 05E7D218D3 for ; Fri, 5 Apr 2019 15:16:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="mtp2PKi+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 05E7D218D3 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=ZEvAq+LTuDyn389lDTD83H6jQQyB64T4nlA/+VvSXec=; b=mtp2PKi+WlE5j4nVchHHcmLgV I+L8QYk5xbGd81aQKaF1cuy0Sk2gHiVz5jejk5TgGjb7FVzFF350zSc0zEYM+nmY1cXLoc4lzP1zV A3FOQ83KmoAXiwZ2VNvcsfs3AJGrpZz9FvFpBz8qoWrAxNfvz1RwfHyzmtutB/tqfoxAxJti/3EYq HlNWZ0NLu7W+CPyPgBMRZCQTiWMBMIm/DQtbYO3aKC88svoi7gaRnmcP4hMEGc0YZEDQmsZDjtK+G xKPmXPL2WNTckxDztR0JV9aI8yQz6tyJPFJkc5w9CxaWSBjkDlkl/3z8DGkMAfUcjVXKRNG3FqrB5 mXfpLxn8Q==; 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 1hCQZV-0003Yh-4Y; Fri, 05 Apr 2019 15:16:01 +0000 Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hCQZS-0003XU-6X for linux-arm-kernel@lists.infradead.org; Fri, 05 Apr 2019 15:15:59 +0000 X-Originating-IP: 90.88.30.125 Received: from localhost (aaubervilliers-681-1-89-125.w90-88.abo.wanadoo.fr [90.88.30.125]) (Authenticated sender: maxime.ripard@bootlin.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 56B7860010; Fri, 5 Apr 2019 15:15:53 +0000 (UTC) Date: Fri, 5 Apr 2019 17:15:52 +0200 From: Maxime Ripard To: Nicolas Dufresne Subject: Re: [PATCH RESEND v7 1/2] media: uapi: Add H264 low-level decoder API compound controls. Message-ID: <20190405151552.biesirbs35uivk7d@flea> References: <7cd913545cfc80fa9999839c62c4bf7b354a7904.1554380738.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-20190405_081558_536345_A81777E6 X-CRM114-Status: GOOD ( 23.20 ) 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 , Jens Kuske , linux-sunxi , Linux Kernel Mailing List , Jernej Skrabec , Tomasz Figa , Paul Kocialkowski , Chen-Yu Tsai , Hans Verkuil , Laurent Pinchart , Sakari Ailus , Guenter Roeck , Ezequiel Garcia , Pawel Osciak , Linux Media Mailing List Content-Type: multipart/mixed; boundary="===============0315863790151670546==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============0315863790151670546== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="t2qijco5lkwnrc7e" Content-Disposition: inline --t2qijco5lkwnrc7e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Nicolas, On Thu, Apr 04, 2019 at 11:41:13AM -0400, Nicolas Dufresne wrote: > > > > + * - __u16 > > > > + - ``pic_width_in_mbs_minus1`` > > > > + - > > > > + * - __u16 > > > > + - ``pic_height_in_map_units_minus1`` > > > > + - > > > > > > We recently had some reflection with Alex that this is redundant with > > > the width and height in the OUTPUT format. It may also apply to some > > > other fields in these structs. I feel like they should be removed and > > > passed via corresponding generic V4L2 properties - format, selection, > > > etc. > > > > > > The same problem is also present in the MPEG2 controls. In fact, there > > > was a patch already which used some fields from the controls to > > > calculate the destination buffer strides, rather than bytesperline in > > > the format. > > > > > > Since we're in staging, it could be done with a follow-up patch, though. > > > > Just my two cents. I played with some codecs a while back. IIRC some > > specify a "codec" size in addition to the actual picture size, like > > when the encoder does padding to fit the requirements of the codec > > (spec). Is this needed anywhere? > > With state-less encoders, the headers, which contains the crop > information is created by userspace and for state less decoder, the > headers that contains this information is parsed by userspace. So I > believe that in theory, the accelerator does not strictly need to be > aware of the cropped dimensions. > > Another thing, is that there is not guarantied matches between e.g. > depth of the chrome/luma and the final image buffers. Some hardware may > have bandwidth limitation or internal converter and could possibly > decode 10bit data into 8bit buffers. > > A third reason why I would not try and encode this header information > is that there can be multiple PPS/SPS at the same time, and I think > it's confusing if the relevant information to differentiate them is > removed. Sorry if that sounds a bit dumb, but it's not really clear to me if you're arguing for the removal of the data as Tomasz suggests, or if you want to keep them. The first paragrah seems to advocate for the former, but the two others for the latter. Thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com --t2qijco5lkwnrc7e Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXKdxKAAKCRDj7w1vZxhR xaguAQDVqL8citHvAI0AYhkqcltH5ypA6lOK0dh6sIpwALsmDwEA3MEjg5BzYQbl HkVCdLdoLNkzR2QAVGyty1UFWk84Zgw= =+ba4 -----END PGP SIGNATURE----- --t2qijco5lkwnrc7e-- --===============0315863790151670546== 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 --===============0315863790151670546==--