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=-1.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,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 2ABE8C282C6 for ; Thu, 24 Jan 2019 20:14:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E1385217D7 for ; Thu, 24 Jan 2019 20:14:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ndufresne-ca.20150623.gappssmtp.com header.i=@ndufresne-ca.20150623.gappssmtp.com header.b="P5KXRuLH" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730463AbfAXUOX (ORCPT ); Thu, 24 Jan 2019 15:14:23 -0500 Received: from mail-qt1-f194.google.com ([209.85.160.194]:41019 "EHLO mail-qt1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730195AbfAXUOV (ORCPT ); Thu, 24 Jan 2019 15:14:21 -0500 Received: by mail-qt1-f194.google.com with SMTP id l12so8199213qtf.8 for ; Thu, 24 Jan 2019 12:14:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ndufresne-ca.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=/eLWF2nBpm4xYIb4J+nXrGXHgxha/99iWqDqjCF/hxo=; b=P5KXRuLHrM1JXw/KPqJrZ56CtTGz/p65b9igENNu130Zl7tjMfvMNqltUxMSlxRza0 A2gG722/oO9+UCYEzggDE7D7sMKNbuWnhag25c3hWzGWc/DpuB6GydkuIgZk/X5YfYop WNw8zqLVLOAUNBIEW/TeLEwKu5GA59cQ6M9AQDKWlT/3zobTCt6XB20VQ7uOOlFPSwbX h7WynjvTiOwquXraaQH8r6i+1tMiAAZ0WluRqvRbfANEVShwbktHlB8nIMZaFBkqtJbW uXgQEdFrpktsoZtkuKBVajv/8Xcdw2ORyNxgUsBeJbj9UzJLnGQtFJHsES7alvWXazvn 6qtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=/eLWF2nBpm4xYIb4J+nXrGXHgxha/99iWqDqjCF/hxo=; b=rOlC4ZVWVdSkmwxHq/VrXRj94cj3L+RWepQtcTvV0tCYE233ZZOYEr5QjTSjtT4+uW FPQtYkgzYddXHKwI8cIlkoz0EJ30idPg0pPtytUUObplrBEN1CDFm63/C7qn9qLJs3Or eDj3V+wq3aXRZ3eji1/iPsrrBkfMMJKNUq4nJE5ZAsTXz/RHVfak61UGoLnuj/+fzSXK Nshmt6L4oWbg87zaOy1SX05NMiMbALNkxH+CJGGsMqaYBVKZ7WuN2x64wG9AcV+PhxZx T6ouRs85VUBPW78aMSwSsVk8hGOvKkeDsaaxIJ8O9U01cZJu6iep0/IYpB5UMd8ESTlH N0TQ== X-Gm-Message-State: AJcUukenfXD24vXD3z5c7grh+JU4q0N1nnSTXQjDblkOdLA1q0WMONJO PdsubgxKzaAHt+mqTlFzdT/Vlw== X-Google-Smtp-Source: ALg8bN7sCPqhhuhQLqnV3zzkNz/+DQAxZbBpMvkozYAsPmK1x1StShsRhRfWSdDb8EAnlV+Z0zpdvw== X-Received: by 2002:aed:2f82:: with SMTP id m2mr8375505qtd.4.1548360860574; Thu, 24 Jan 2019 12:14:20 -0800 (PST) Received: from skullcanyon ([192.222.193.21]) by smtp.gmail.com with ESMTPSA id r24sm77410788qtr.2.2019.01.24.12.14.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 24 Jan 2019 12:14:19 -0800 (PST) Message-ID: <0452db20a894c1c4cce263b7e07ba274a58aa8fa.camel@ndufresne.ca> Subject: Re: [PATCH v2 2/2] media: docs-rst: Document memory-to-memory video encoder interface From: Nicolas Dufresne To: Hans Verkuil , Tomasz Figa Cc: Linux Media Mailing List , Linux Kernel Mailing List , Mauro Carvalho Chehab , =?UTF-8?Q?Pawe=C5=82_O=C5=9Bciak?= , Alexandre Courbot , Kamil Debski , Andrzej Hajda , Kyungmin Park , Jeongtae Park , Philipp Zabel , Tiffany Lin , Andrew-CT Chen , Stanimir Varbanov , Todor Tomov , Paul Kocialkowski , Laurent Pinchart , dave.stevenson@raspberrypi.org, Ezequiel Garcia , Maxime Jourdan Date: Thu, 24 Jan 2019 15:14:18 -0500 In-Reply-To: <75334288-69af-6680-fbe7-2dd5ef2462ea@xs4all.nl> References: <20181022144901.113852-1-tfiga@chromium.org> <20181022144901.113852-3-tfiga@chromium.org> <4cd223f0-b09c-da07-f26c-3b3f7a8868d7@xs4all.nl> <75334288-69af-6680-fbe7-2dd5ef2462ea@xs4all.nl> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.4 (3.30.4-1.fc29) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le mercredi 23 janvier 2019 à 14:04 +0100, Hans Verkuil a écrit : > > > Does this return the same set of formats as in the 'Querying Capabilities' phase? > > > > > > > It's actually an interesting question. At this point we wouldn't have > > the OUTPUT resolution set yet, so that would be the same set as in the > > initial query. If we set the resolution (with some arbitrary > > pixelformat), it may become a subset... > > But doesn't setting the capture format also set the resolution? > > To quote from the text above: > > "The encoder will derive a new ``OUTPUT`` format from the ``CAPTURE`` format > being set, including resolution, colorimetry parameters, etc." > > So you set the capture format with a resolution (you know that), then > ENUM_FMT will return the subset for that codec and resolution. > > But see also the comment at the end of this email. I'm thinking that the fact that there is no "unset" value for pixel format creates a certain ambiguity. Maybe we could create a new pixel format, and all CODEC driver could have that set by default ? Then we can just fail STREAMON if that format is set. That being said, in GStreamer, I have split each elements per CODEC, and now only enumerate the information "per-codec". That makes me think this "global" enumeration was just a miss-use of the API / me learning to use it. Not having to implement this rather complex thing in the driver would be nice. Notably, the new Amlogic driver does not have this "Querying Capabilities" phase, and with latest GStreamer works just fine. Nicolas