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.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED 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 C74AAECDFAC for ; Tue, 9 Oct 2018 17:48:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7345A21479 for ; Tue, 9 Oct 2018 17:48:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7345A21479 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=paulk.fr Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727281AbeJJBGf (ORCPT ); Tue, 9 Oct 2018 21:06:35 -0400 Received: from leonov.paulk.fr ([185.233.101.22]:35400 "EHLO leonov.paulk.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726418AbeJJBGe (ORCPT ); Tue, 9 Oct 2018 21:06:34 -0400 Received: from gagarine.paulk.fr (gagarine [192.168.1.127]) by leonov.paulk.fr (Postfix) with ESMTPS id 4148EBFE24; Tue, 9 Oct 2018 19:48:27 +0200 (CEST) Received: by gagarine.paulk.fr (Postfix, from userid 114) id 27EFEC0FFD; Tue, 9 Oct 2018 19:48:26 +0200 (CEST) Received: from shepard (unknown [192.168.1.1]) by gagarine.paulk.fr (Postfix) with ESMTPSA id 4BA82C0FE9; Tue, 9 Oct 2018 19:48:23 +0200 (CEST) Message-ID: <21f6b66ea646c6e24e5801023557e8b5db3831d6.camel@paulk.fr> Subject: Re: [RFC PATCH v2] media: docs-rst: Document m2m stateless video decoder interface From: Paul Kocialkowski To: Tomasz Figa Cc: Alexandre Courbot , Mauro Carvalho Chehab , Hans Verkuil , Pawel Osciak , Linux Media Mailing List , Linux Kernel Mailing List Date: Tue, 09 Oct 2018 19:48:09 +0200 In-Reply-To: References: <20181004081119.102575-1-acourbot@chromium.org> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-NJuvIF4jZV9m01lN8MZm" X-Mailer: Evolution 3.28.5 Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-NJuvIF4jZV9m01lN8MZm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Le mardi 09 octobre 2018 =C3=A0 16:30 +0900, Tomasz Figa a =C3=A9crit : > On Thu, Oct 4, 2018 at 9:46 PM Paul Kocialkowski wrote= : > >=20 > > Hi, > >=20 > > Here are a few minor suggestion about H.264 controls. > >=20 > > Le jeudi 04 octobre 2018 =C3=A0 17:11 +0900, Alexandre Courbot a =C3=A9= crit : > > > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Doc= umentation/media/uapi/v4l/extended-controls.rst > > > index a9252225b63e..9d06d853d4ff 100644 > > > --- a/Documentation/media/uapi/v4l/extended-controls.rst > > > +++ b/Documentation/media/uapi/v4l/extended-controls.rst > > > @@ -810,6 +810,31 @@ enum v4l2_mpeg_video_bitrate_mode - > > > otherwise the decoder expects a single frame in per buffer. > > > Applicable to the decoder, all codecs. > > >=20 > > > +.. _v4l2-mpeg-h264: > > > + > > > +``V4L2_CID_MPEG_VIDEO_H264_SPS`` > > > + Instance of struct v4l2_ctrl_h264_sps, containing the SPS of to = use with > > > + the next queued frame. Applicable to the H.264 stateless decoder= . > > > + > > > +``V4L2_CID_MPEG_VIDEO_H264_PPS`` > > > + Instance of struct v4l2_ctrl_h264_pps, containing the PPS of to = use with > > > + the next queued frame. Applicable to the H.264 stateless decoder= . > > > + > > > +``V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX`` > >=20 > > For consistency with MPEG-2 and upcoming JPEG, I think we should call > > this "H264_QUANTIZATION". >=20 > I'd rather stay consistent with H.264 specification, which uses the > wording as defined in Alex's patch. Otherwise it would be difficult to > correlate between the controls and the specification, which is > something that the userspace developer would definitely need to > understand how to properly parse the stream and obtain the decoding > parameters. Okay, I agree this makes more sense than trying to keep the names consistent across codecs. > >=20 > > > + Instance of struct v4l2_ctrl_h264_scaling_matrix, containing the= scaling > > > + matrix to use when decoding the next queued frame. Applicable to= the H.264 > > > + stateless decoder. > > > + > > > +``V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAM`` > >=20 > > Ditto with "H264_SLICE_PARAMS". > >=20 >=20 > It doesn't seem to be related to the spec in this case and "params" > sounds better indeed. Cheers, Paul --=-NJuvIF4jZV9m01lN8MZm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEAbcMXZQMtj1fphLChP3B6o/ulQwFAlu86dkACgkQhP3B6o/u lQwvgw/+NzUyPZU/e3+Obp5UTRuXVtUTm/zTLzu9q6MRD4VMlAlrs4IEMDwEWk7/ oBIaNWSTF2cz//wPpfz6RqnqHHK9BsKVOBYi13o1SGUFRZPK2g50H1iloSNvfwRT kZ8gZgDOM4UGyly9zwv749pJHoWjcXFzXU+2kFdhdcbpjxJfEVKS9CmgUJH/ZptG aixn6UXkToZ24Hm/QazAQcPk4G4gqJHB5tE6AP/QhrgntS3U+JWcPayStSx1zaJp UHxDqGjLxHMbw0g7haK7WngsOBbi+v9AQJeFaoHDI/P7VhJd18AirFnuEYr90CjA OfAo2MPK900abYmtgm2IRTGO98G5zAwlZ0GlX5TVo0mdIGKeo6oZZGEnsYMhaX3D LWR6EY4UBhZT0M6XlK1P+85AHknzw6kcorFtNrD3GRIx4BGL8f4o/gnxD1Fx/yo0 W/t5ywwgw52M8YOt4ZRNIxuWOUiewzRS79sWNPTHEELTDs8lna2ONUxFIh3CL7w8 MuVCcQvpCX9vAjRkVAAOdXjZxM11aOfduvKvZIvukDNpSgumqq8W4v3ZHib4TF9s rBN/6L/NRoLqX+SupzL4egAfNHSg/OKBDzR3b9BOgbyKAEa0cFPyQXHl+TXx2eld qfiO1UUbGCJcSgLP+4KVut6AUX6sZe3BzhBV0gJMu+9o21EfeL0= =62QB -----END PGP SIGNATURE----- --=-NJuvIF4jZV9m01lN8MZm--