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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS 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 0A224C64EAD for ; Tue, 9 Oct 2018 06:39:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B43F4213A2 for ; Tue, 9 Oct 2018 06:39:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B43F4213A2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xs4all.nl 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 S1726693AbeJINzB (ORCPT ); Tue, 9 Oct 2018 09:55:01 -0400 Received: from lb2-smtp-cloud9.xs4all.net ([194.109.24.26]:59002 "EHLO lb2-smtp-cloud9.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725887AbeJINzB (ORCPT ); Tue, 9 Oct 2018 09:55:01 -0400 Received: from [192.168.2.10] ([212.251.195.8]) by smtp-cloud9.xs4all.net with ESMTPA id 9lg4gWNu0SskC9lg7glSDl; Tue, 09 Oct 2018 08:39:36 +0200 Subject: Re: [PATCH 1/2] media: docs-rst: Document memory-to-memory video decoder interface To: Tomasz Figa Cc: Linux Media Mailing List , Linux Kernel Mailing List , Stanimir Varbanov , Mauro Carvalho Chehab , Pawel Osciak , Alexandre Courbot , kamil@wypas.org, a.hajda@samsung.com, Kyungmin Park , jtp.park@samsung.com, Philipp Zabel , =?UTF-8?B?VGlmZmFueSBMaW4gKOael+aFp+ePiik=?= , =?UTF-8?B?QW5kcmV3LUNUIENoZW4gKOmZs+aZuui/qik=?= , todor.tomov@linaro.org, nicolas@ndufresne.ca, Paul Kocialkowski , Laurent Pinchart , dave.stevenson@raspberrypi.org, Ezequiel Garcia , Maxime Jourdan References: <20180724140621.59624-1-tfiga@chromium.org> <20180724140621.59624-2-tfiga@chromium.org> <37a8faea-a226-2d52-36d4-f9df194623cc@xs4all.nl> <1dc5fd0b-61f0-545a-fea6-bd90721e144b@xs4all.nl> From: Hans Verkuil Message-ID: <79b6e542-4b81-7cc2-df78-74c012c5c478@xs4all.nl> Date: Tue, 9 Oct 2018 08:39:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfIONemGJ1QY9jgJN8+LfPFPXb6+iNDWFKFHdInJHEmaWvxPamKSIvftUK0+gOI6ZKifWLbUnJXW5+inbM2u1/x5JcUNogFSxrddbj+a1datCkDya4lBK dOOMPbzMy5Up86b4IPz34V0LNerJsshovgpeYgf+0Q91LurBSHn9FEfzl8ZT5Dk/e6Gop92KVwOXpPsOpksSyaRLXX+uVWYcy+lqeg5fxOD2Ay8O0Dmel7Mj A7oyKoC8e09qp4s/t3A4e7j35HdB50WH00thaJ5IP7/6NO0CJYEitIsQHvykKs+bRT8G9UywQZ7AYCjRSa30EVvpslbHxOwldk9tUX3ev0MtgDFk3yEeFvfI OPIcjJR0IlUKyMFky8UiEJ3SkJr2bncY6Qix80YKpIAYLutNoCO8HD7VjTEsvz8TuHS/1K7gQDFlLwGPNavkWzCnelsak152gZqIicrbQTzGgVI2jSAkgz77 tO6MOzD9AKZz7ZoUlaSOH8YUuC+kh2x3BM0iof/4OErObAMB6uTzePeJWa40aYIdyAALBzoOXAoDQOu/6wq+poVYXVGaFXn0GpuJgzEwbUsRqL07sfRigk80 JMAuXBY9M3Sot93A+a+n0C1iRr2TE/CA+l24FZ3I1LnLvWBk4fjtq9qyU1Is7HUYweSQllDacCyyaSrzecDeOZ0CeEIYIjAe5gmx5ynLqN5T1bH8tAT1RAlv obMyVuA10Mg/BWC4ti67WU8YbinWj1WtHCSANhT6FqgjK160pls9Hk2YHIwjD70BalktvzEEJthEasnJFcsYnLZTQ5kR2Z8S+EImTE7gYP6eoYfWffig6nno 3ld7G9dSVv6T3NxIkcQoBSwaO/SzbsVPwbn5w5ou5akXs+enMRElb3eHgsIdyEBak0foC49H8DBz+mDUQlk= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/09/2018 06:23 AM, Tomasz Figa wrote: > On Mon, Oct 8, 2018 at 9:22 PM Hans Verkuil wrote: >> >> On 09/19/2018 12:17 PM, Tomasz Figa wrote: >>> Hi Hans, >>> >>> On Thu, Jul 26, 2018 at 7:20 PM Tomasz Figa wrote: >>>> >>>> Hi Hans, >>>> >>>> On Wed, Jul 25, 2018 at 8:59 PM Hans Verkuil wrote: >>>>> >>>>> Hi Tomasz, >>>>> >>>>> Many, many thanks for working on this! It's a great document and when done >>>>> it will be very useful indeed. >>>>> >>>>> Review comments follow... >>>> >>>> Thanks for review! >>>> >>>>> >>>>> On 24/07/18 16:06, Tomasz Figa wrote: >>> [snip] >>>>>> +13. Allocate destination (raw format) buffers via :c:func:`VIDIOC_REQBUFS` >>>>>> + on the ``CAPTURE`` queue. >>>>>> + >>>>>> + * **Required fields:** >>>>>> + >>>>>> + ``count`` >>>>>> + requested number of buffers to allocate; greater than zero >>>>>> + >>>>>> + ``type`` >>>>>> + a ``V4L2_BUF_TYPE_*`` enum appropriate for ``CAPTURE`` >>>>>> + >>>>>> + ``memory`` >>>>>> + follows standard semantics >>>>>> + >>>>>> + * **Return fields:** >>>>>> + >>>>>> + ``count`` >>>>>> + adjusted to allocated number of buffers >>>>>> + >>>>>> + * The driver must adjust count to minimum of required number of >>>>>> + destination buffers for given format and stream configuration and the >>>>>> + count passed. The client must check this value after the ioctl >>>>>> + returns to get the number of buffers allocated. >>>>>> + >>>>>> + .. note:: >>>>>> + >>>>>> + To allocate more than minimum number of buffers (for pipeline >>>>>> + depth), use G_CTRL(``V4L2_CID_MIN_BUFFERS_FOR_CAPTURE``) to >>>>>> + get minimum number of buffers required, and pass the obtained value >>>>>> + plus the number of additional buffers needed in count to >>>>>> + :c:func:`VIDIOC_REQBUFS`. >>>>> >>>>> >>>>> I think we should mention here the option of using VIDIOC_CREATE_BUFS in order >>>>> to allocate buffers larger than the current CAPTURE format in order to accommodate >>>>> future resolution changes. >>>> >>>> Ack. >>>> >>> >>> I'm about to add a paragraph to describe this, but there is one detail >>> to iron out. >>> >>> The VIDIOC_CREATE_BUFS ioctl accepts a v4l2_format struct. Userspace >>> needs to fill in this struct and the specs says that >>> >>> "Usually this will be done using the VIDIOC_TRY_FMT or VIDIOC_G_FMT >>> ioctls to ensure that the requested format is supported by the >>> driver." >>> >>> However, in case of a decoder, those calls would fixup the format to >>> match the currently parsed stream, which would likely resolve to the >>> current coded resolution (~hardware alignment). How do we get a format >>> for the desired maximum resolution? >> >> You would call G_FMT to get the current format/resolution, then update >> width and height and call TRY_FMT. >> >> Although to be honest you can also just set pixelformat and width/height >> and zero everything else and call TRY_FMT directly, skipping the G_FMT >> ioctl. >> > > Wouldn't TRY_FMT adjust the width and height back to match current stream? Huh. Hmm. Grrr. Good point and I didn't read your original comment carefully enough. Suggestions on a postcard... Regards, Hans