From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomasz Figa Subject: Re: [PATCH 10/10] venus: dec: make decoder compliant with stateful codec API Date: Wed, 24 Apr 2019 21:39:21 +0900 Message-ID: References: <20190117162008.25217-1-stanimir.varbanov@linaro.org> <20190117162008.25217-11-stanimir.varbanov@linaro.org> <60b3efff-31c1-bc04-8af9-deebb8bc013a@xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Stanimir Varbanov Cc: Hans Verkuil , Linux Media Mailing List , Mauro Carvalho Chehab , Linux Kernel Mailing List , linux-arm-msm , Vikash Garodia , Alexandre Courbot , Malathi Gottam List-Id: linux-arm-msm@vger.kernel.org On Wed, Apr 24, 2019 at 9:15 PM Stanimir Varbanov wrote: > > Hi Hans, > > On 2/15/19 3:44 PM, Hans Verkuil wrote: > > Hi Stanimir, > > > > I never paid much attention to this patch series since others were busy > > discussing it and I had a lot of other things on my plate, but then I heard > > that this patch made G_FMT blocking. > > OK, another option could be to block REQBUF(CAPTURE) until event from hw > is received that the stream is parsed and the resolution is correctly > set by application. Just to note that I'd think to this like a temporal > solution until gstreamer implements v4l events. > > Is that looks good to you? Hmm, I thought we concluded that gstreamer sets the width and height in OUTPUT queue before querying the CAPTURE queue and so making the driver calculate the CAPTURE format based on what's set on OUTPUT would work fine. Did I miss something? Best regards, Tomasz 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=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, T_DKIMWL_WL_HIGH,URIBL_BLOCKED autolearn=unavailable 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 91F22C10F11 for ; Wed, 24 Apr 2019 12:39:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6129320811 for ; Wed, 24 Apr 2019 12:39:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="VTntqaoB" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730011AbfDXMjg (ORCPT ); Wed, 24 Apr 2019 08:39:36 -0400 Received: from mail-oi1-f195.google.com ([209.85.167.195]:41471 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729750AbfDXMjf (ORCPT ); Wed, 24 Apr 2019 08:39:35 -0400 Received: by mail-oi1-f195.google.com with SMTP id v7so14120406oie.8 for ; Wed, 24 Apr 2019 05:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vyXfa149xflFPUebzbBDNz6s0lUGYHuiRaKn3DL9Cs4=; b=VTntqaoByvKi4O60oIfPkpb91X5rmSYz9Q3BhXE8h28107pN+W8kpnWHQzAQvNjGGA dOaI53lntSNvaer6TNQoqeJ2F4Ndqc8MFoPtG2wlSgCudqwqV3IlAvpKqQX51IessjEv RUr9Sqsb6/x8EhdRucXIiWJkBWPL0NRKRkUn0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vyXfa149xflFPUebzbBDNz6s0lUGYHuiRaKn3DL9Cs4=; b=efyNUYWv6WFtsaeIyWMThcxp8hyicLnvSWbKPwoYjuQWTF7XmmPxQvS/7cFe8SJbMr iB3dvFO23a7CndI/K4IrzK6h5Ew7ZsMWXeDNFmQrrxvvtq3Lz+Bldjh3OwCgxwZBrsaF SiDBUSHW6b1pYHOEjKQTM0vp1PTNxcRx7zyxXvgE9YJACDMj/TVK+qtn1F/A/4VXQwzk ANk/ziJcVcX8jrCz2h8ZfEhycPbFGJi/Csm34ailQkAueffGHlqmeWt4ulArbKjUQ/Nl pNo54Cw0o+jS7/2IZRKVwewvqM1sA4sspOOJ72nZ1lt1v3DhXbAr2AYiRX5lnmo5yKKe PB/A== X-Gm-Message-State: APjAAAX2qRKXuif74md+4eD5kgfsYZqvwi8J5ZM8PCw3Pn7j9qfaQZVK +G6Eh0WSU4yMgcbKuTQZJQuctdUuB/Q= X-Google-Smtp-Source: APXvYqw9oV289j7UkrjPc+Qgdten6m0dKWYuqK3QP7N8dFr+OCqAhmP/RftnOL8CFKjS80qWanIZKQ== X-Received: by 2002:aca:ed88:: with SMTP id l130mr5201955oih.70.1556109574506; Wed, 24 Apr 2019 05:39:34 -0700 (PDT) Received: from mail-ot1-f48.google.com (mail-ot1-f48.google.com. [209.85.210.48]) by smtp.gmail.com with ESMTPSA id u22sm7236804otk.49.2019.04.24.05.39.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Apr 2019 05:39:33 -0700 (PDT) Received: by mail-ot1-f48.google.com with SMTP id o39so2861514ota.6 for ; Wed, 24 Apr 2019 05:39:33 -0700 (PDT) X-Received: by 2002:a9d:6f90:: with SMTP id h16mr7097977otq.152.1556109572667; Wed, 24 Apr 2019 05:39:32 -0700 (PDT) MIME-Version: 1.0 References: <20190117162008.25217-1-stanimir.varbanov@linaro.org> <20190117162008.25217-11-stanimir.varbanov@linaro.org> <60b3efff-31c1-bc04-8af9-deebb8bc013a@xs4all.nl> In-Reply-To: From: Tomasz Figa Date: Wed, 24 Apr 2019 21:39:21 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 10/10] venus: dec: make decoder compliant with stateful codec API To: Stanimir Varbanov Cc: Hans Verkuil , Linux Media Mailing List , Mauro Carvalho Chehab , Linux Kernel Mailing List , linux-arm-msm , Vikash Garodia , Alexandre Courbot , Malathi Gottam Content-Type: text/plain; charset="UTF-8" Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Message-ID: <20190424123921.jzoCstlIiJV1lcyUMKLSZ3vLrpaHbqyBwtii2nAAXD4@z> On Wed, Apr 24, 2019 at 9:15 PM Stanimir Varbanov wrote: > > Hi Hans, > > On 2/15/19 3:44 PM, Hans Verkuil wrote: > > Hi Stanimir, > > > > I never paid much attention to this patch series since others were busy > > discussing it and I had a lot of other things on my plate, but then I heard > > that this patch made G_FMT blocking. > > OK, another option could be to block REQBUF(CAPTURE) until event from hw > is received that the stream is parsed and the resolution is correctly > set by application. Just to note that I'd think to this like a temporal > solution until gstreamer implements v4l events. > > Is that looks good to you? Hmm, I thought we concluded that gstreamer sets the width and height in OUTPUT queue before querying the CAPTURE queue and so making the driver calculate the CAPTURE format based on what's set on OUTPUT would work fine. Did I miss something? Best regards, Tomasz