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 165B4C43381 for ; Thu, 14 Feb 2019 16:19:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C4E2320823 for ; Thu, 14 Feb 2019 16:19: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="KvphQnwz" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2395397AbfBNQTV (ORCPT ); Thu, 14 Feb 2019 11:19:21 -0500 Received: from mail-qk1-f196.google.com ([209.85.222.196]:34935 "EHLO mail-qk1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730918AbfBNQTT (ORCPT ); Thu, 14 Feb 2019 11:19:19 -0500 Received: by mail-qk1-f196.google.com with SMTP id w204so3919976qka.2 for ; Thu, 14 Feb 2019 08:19:18 -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=AxuHCqH7c+QRUhY3Jid4ATKz6AXdTTJj/yE7k5txmuc=; b=KvphQnwzQ6hxJrUOiBUpJSyK0dNjgTP5ITt7+sdjFElkm00lYkoWceeuKcdJjTpZZ6 1/96wcrGhRpkfWGESn8CfVoC9ZLMi6L4D5BanePYHCAKl7iMet2Dy9Gnq3aMsA0aM7t8 A6iq54ZISKz/i1xUERGRF3KHOhrNozVkFYIazH5vNRyb93vH6mmddKk/lNX/6ZMZXM9M JKeyuMjUu8JLDUnkvNkFE0IrnTFCaL6gxOc8nG3yyMCXZ8aCfvyih/swfZeSlr05MbDR LbLtv3/+MYHC4Mbhw6g1G//MzEqlEGGHVwXnjl8TgpznUO35E/Zsr5bGij7DqjBRwqYE /Ujw== 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=AxuHCqH7c+QRUhY3Jid4ATKz6AXdTTJj/yE7k5txmuc=; b=fgK+lEON+gGgEpfU2FLvTtRVVdKD8RM/iYN36C5kx2L6Zszaeo+Ncz4S7VjfjG2C9P XYMiYIsHivVpiMfttgQWDYBMQp0Xxm8B+JUPVleQpy86sphOCGGtm6gfJLLL+HXxJJ8Y muvUFgAuzJd8dZEbGJi6kdMUU4nm1AK8MYOk/nPQEY4WGaqvxbVnUyJ28WdeTzRl5ZLM Z9Scl/73kSCguJkzGW3lb4IOTywd7oKc40HcIpjdchxJuIedLRVQfs1YhWLp2ipSIWWH mOo1fTsmNPY5UcC64awBSYiYTR6wH7bobrLIJo/gdua/8YUi4hdMq/OfLSoCx8mkrkca XXAA== X-Gm-Message-State: AHQUAubdJFbHP81LRADlw9h5uON6cRn+51jAEqFUegh8AaVsjf1du/Ow MskSOYf+8QFNIlFczRkkAzkaug== X-Google-Smtp-Source: AHgI3IYgb3YZOLuWe4trND68o2DvKWBNdl+FBr16n3rCZfLhyHzDVzrviq72ySINlIM1iNHWIb0p1Q== X-Received: by 2002:a37:8105:: with SMTP id c5mr3465494qkd.116.1550161157696; Thu, 14 Feb 2019 08:19:17 -0800 (PST) Received: from skullcanyon ([192.222.193.21]) by smtp.gmail.com with ESMTPSA id y11sm2520187qky.2.2019.02.14.08.19.15 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 14 Feb 2019 08:19:16 -0800 (PST) Message-ID: <69347bdc0065b395f44673fea19e2b798c90fbc3.camel@ndufresne.ca> Subject: Re: [PATCH 10/10] venus: dec: make decoder compliant with stateful codec API From: Nicolas Dufresne To: Tomasz Figa , Hans Verkuil Cc: Philipp Zabel , Stanimir Varbanov , Linux Media Mailing List , Mauro Carvalho Chehab , Linux Kernel Mailing List , linux-arm-msm , Vikash Garodia , Alexandre Courbot , Malathi Gottam Date: Thu, 14 Feb 2019 11:19:15 -0500 In-Reply-To: References: <20190117162008.25217-1-stanimir.varbanov@linaro.org> <20190117162008.25217-11-stanimir.varbanov@linaro.org> <28069a44-b188-6b89-2687-542fa762c00e@linaro.org> <57419418d377f32d0e6978f4e4171c0da7357cbb.camel@ndufresne.ca> <1548938556.4585.1.camel@pengutronix.de> <1f8485785a21c0b0e071a3a766ed2cbc727e47f6.camel@ndufresne.ca> 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 jeudi 14 février 2019 à 11:43 +0900, Tomasz Figa a écrit : > > > > No, I exactly meant the OUTPUT queue. The behavior of s5p-mfc in case > > > > of the format not being detected yet is to waits for any pending > > > > bitstream buffers to be processed by the decoder before returning an > > > > error. > > > > > > > > See https://elixir.bootlin.com/linux/v5.0-rc5/source/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c#L329 > > > > > > It blocks?! That shouldn't happen. Totally against the spec. > > > > > > > Yeah and that's what this patch tries to implement in venus as well > > and is seemingly required for compatibility with gstreamer... > > > > Hans, Nicolas, any thoughts? Thinking about this, if CODA managed to make it work without this, and without the source change event, we should probably study more this code and propose to do this instead of blocking (which is the ugly but easy solution). I'm sure it was a bit of juggle to pass the information correctly from input to output, but that would bring "compatibility" with un-ported userspace. If we had a codec specific framework (making a wish here), we could handle that for the codec, a bit like the code that emulates CROP on top of G/S_SELECTION. Meanwhile, I'm trying to get some time allocated to implement the event in GStreamer, as this would be sufficient argument to say that newly introduce drivers don't need to care, you just need newer userspace. For Venus it's a bit difficult, since they have customers using GStreamer already, and it's quite common to run newer kernel with much older userspace (and expect the userspace to keep working). Nicolas