Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp8910189ybi; Wed, 10 Jul 2019 01:28:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqzrOh7WnhA0PEV0K2SLFlTYjU/un4TSJJWmB6XpYhrYDUc+NEueuluq+U7ae5IW6yEIN39F X-Received: by 2002:a17:902:100a:: with SMTP id b10mr36793025pla.338.1562747324731; Wed, 10 Jul 2019 01:28:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562747324; cv=none; d=google.com; s=arc-20160816; b=hMZl+BsKtjqvjrrKFewpKeK9LL+kp+VQF94KWHh/F9PXELW1a87G6Ghgej1pTewLgC jIdtolzSJ6h2+/9D99SCohsfNQ4Rz38bkVDOiHT/p+9dbgH1/WIY8eDb1dtIrMxmPe53 zFT3nLC2KI0llP7BoJolB2JROpfEF+xVsCSEG2x9UUTO2dWCsSvFawJ9RDV/QYcsecsr ctXfTMU6rfeRH6784sInfRwzrWuw2CaCfCInz9iQxC0IEvjmsZ7Po3g5QbU7/SyKnjX/ YbInk1wdV2b167EU30A8RGspnBYB/KjE9qi0kURavyoaZDWwe5e1MTdclVyNnWjYid7l Pf1Q== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=U+LVDjCMPsz6ZS+RThpZCTrvM1LdTuXJgmEmPMhsFfs=; b=JotannfP5haFWsh24SzOihd6jTL0kX6GZHtRC/jcwugqzeMa3ctYGvA3pJT863cF8L 5MNx0MEJuPyT/Bg36aziKQl4FkbPPCXyigJhorJQ7AyZLl9SuUL3OFHGAy5AvqjD/5lz 4o5X7lFC62ppZPZsAL6WhGdvcFkbk6HSsEgiN6n5fRi7bIhdpHlS3c0UO4Wbd7uBsLQ3 6nKwih9Xz3nV4tDf9qhnhArNkteIQLK22/4NwsFSG/zomaUavAz2+OzMRGBht5otBfDl yp3OLQ+ipfhWB0tf5o/zrjBRPX2IWbdfTby/1pV7ytb3O0xnbCAgbPdj66CDEIu7Q/t7 vHZQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a2si1663502pjs.16.2019.07.10.01.28.29; Wed, 10 Jul 2019 01:28:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727497AbfGJIJd (ORCPT + 99 others); Wed, 10 Jul 2019 04:09:33 -0400 Received: from lb1-smtp-cloud7.xs4all.net ([194.109.24.24]:49885 "EHLO lb1-smtp-cloud7.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726097AbfGJIJc (ORCPT ); Wed, 10 Jul 2019 04:09:32 -0400 Received: from [IPv6:2001:983:e9a7:1:10f:829c:8d05:60ea] ([IPv6:2001:983:e9a7:1:10f:829c:8d05:60ea]) by smtp-cloud7.xs4all.net with ESMTPA id l7fMhsLbn0SBql7fOh6R3G; Wed, 10 Jul 2019 10:09:30 +0200 Subject: Re: [PATCHv4 1/2] media: docs-rst: Document memory-to-memory video decoder interface To: Tomasz Figa Cc: Linux Media Mailing List , Linux Kernel Mailing List , Alexandre Courbot , Philipp Zabel , Stanimir Varbanov , Andrew-CT Chen , Tiffany Lin , Pawel Osciak References: <20190603112835.19661-1-hverkuil-cisco@xs4all.nl> <20190603112835.19661-2-hverkuil-cisco@xs4all.nl> From: Hans Verkuil Message-ID: <02da6340-3174-c03b-ffad-cc9a0a58afab@xs4all.nl> Date: Wed, 10 Jul 2019 10:09:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfB8/NX8OMxDhoB5rNNb4Nrxp+O02fe8pwgh4uz7RNaRO/12CMe5NnBdik+t2PDdSBV9zwCfQtcO5GOvH/vCMdvuO4LREs1q/VcPyupkoSXNH/7GpTpy7 /ds4jkR99tFUr+xaJ4FVxvt/mnjXlBEOUHF3cHktbSvNZmeoKH53nX6zQFIQEB4EblOgFmjzjJf8Iuo869qJsUVfty7EZJKO6P1S9NwmTXVQ2Wl7RFuLd6o9 lch5JvNcALsRkSt75o0siIszLNfPOttuEwVy4yhW3D+0kmAnasTTTEx9KpWNJSUHHCdiQzB5ueOP/r1ScpriO8ftobRu1mfiZy1Ir00vLn9CToxs5SG7SaZW ugDgAYGV01aiMA7OX/Z+F4RWKTmlhe635iE0UhVoS4ET9obEWA4fNNHT8JoHU+QkFsAtL16dyt37uY/DHjKGF0UxrBZE2Q3gKqGlRAFxTZ4hkhP4H/yTt27c XurABG4XNozGVHjUMHWiXm+87KUAkfs4TFtdYkGzTCTixylt2PG9+UhO/+i92nhQvfJbrIZT9NfK5KcPsEL++82N3BLcfGGfSpHJCQ== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/3/19 6:58 AM, Tomasz Figa wrote: > Hi Hans, > > On Mon, Jun 3, 2019 at 8:28 PM Hans Verkuil wrote: >> >> From: Tomasz Figa >> >> Due to complexity of the video decoding process, the V4L2 drivers of >> stateful decoder hardware require specific sequences of V4L2 API calls >> to be followed. These include capability enumeration, initialization, >> decoding, seek, pause, dynamic resolution change, drain and end of >> stream. >> >> Specifics of the above have been discussed during Media Workshops at >> LinuxCon Europe 2012 in Barcelona and then later Embedded Linux >> Conference Europe 2014 in Düsseldorf. The de facto Codec API that >> originated at those events was later implemented by the drivers we already >> have merged in mainline, such as s5p-mfc or coda. >> >> The only thing missing was the real specification included as a part of >> Linux Media documentation. Fix it now and document the decoder part of >> the Codec API. >> >> Signed-off-by: Tomasz Figa >> Signed-off-by: Hans Verkuil >> --- >> Documentation/media/uapi/v4l/dev-decoder.rst | 1084 +++++++++++++++++ >> Documentation/media/uapi/v4l/dev-mem2mem.rst | 8 +- >> Documentation/media/uapi/v4l/pixfmt-v4l2.rst | 5 + >> Documentation/media/uapi/v4l/v4l2.rst | 10 +- >> .../media/uapi/v4l/vidioc-decoder-cmd.rst | 41 +- >> 5 files changed, 1132 insertions(+), 16 deletions(-) >> create mode 100644 Documentation/media/uapi/v4l/dev-decoder.rst >> > > Thanks a lot for helping with remaining changes. > > Just one thing inline our team member found recently. > > [snip] >> +Capture setup >> +============= >> + > [snip] >> +4. **Optional.** Set the ``CAPTURE`` format via :c:func:`VIDIOC_S_FMT` on the >> + ``CAPTURE`` queue. The client may choose a different format than >> + selected/suggested by the decoder in :c:func:`VIDIOC_G_FMT`. >> + >> + * **Required fields:** >> + >> + ``type`` >> + a ``V4L2_BUF_TYPE_*`` enum appropriate for ``CAPTURE``. >> + >> + ``pixelformat`` >> + a raw pixel format. > > The client should be able to set the width and height as well. It's a > quite frequent case, especially in DMA-buf import mode, that the > buffers are actually bigger (e.g. more alignment) than what we could > get from the decoder by default. For sane hardware platforms it's > reasonable to expect that such bigger buffers could be handled as > well, as long as we update the width and height here. I've added this: ``width``, ``height`` frame buffer resolution of the decoded stream; typically unchanged from what was returned with :c:func:`VIDIOC_G_FMT`, but it may be different if the hardware supports composition and/or scaling. Is that what you were looking for? > > It's more like a clarification anyway, so if you think it would be > better to just merge the current revision, I could send a follow up > patch. > > Regardless of that and FWIW: > > Reviewed-by: Tomasz Figa Thanks! Hans > > Best regards, > Tomasz >