Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp2449243pxb; Fri, 8 Oct 2021 08:03:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx+TBkwxquuN2fF7kPCgRvsggFr1DYWnq19jg1SM885Njj2J6ksMdPFES8e90F0Q9l4wpH1 X-Received: by 2002:a17:903:246:b0:13a:8c8:8a31 with SMTP id j6-20020a170903024600b0013a08c88a31mr9918175plh.87.1633705429282; Fri, 08 Oct 2021 08:03:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633705429; cv=none; d=google.com; s=arc-20160816; b=qd5R1jIXl6YODgJakbFMxOpjYgWKkzqp6qmyvB3iRt6Vj9TOoR7k7eptSiS9h4k81m kCbxyUX+8wJm32/y+PIpLWHK/pvEo9lhgW/nJfVgrfPf2KkWOOCf5ULF7AGxibAWxKP0 vaWaLnOr7DSnVQLgiOveBteibilOjNkKxI8NJJC1NK95ut+v/wEurDsbFZfekXfzUcLG zH0SfrOk+dXukWPsfW+UAOP+76gBvPVHlmxPsN4X3r3svisiCcoLap1IE6fuSmSE46hK 2/b0oJ5hKPsFizp8jxsphD3LsitJKVvPG8Tj8lK1Pa/rUPjHRJO4vRAHCFeUNfFUFWfr U9tw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=0Cd0z7g+i2z12hwZuJkH9H7tynOoN/9YkihDsbzTwXQ=; b=ptTQ4ESpPyhA7VKk1hEwkheSbqCz0zUxAeC4/Sz2IjI2rYvmThkM5fAqF+SsOteGJU Aw56tF7ME9o3lZ0WiPzxvXLZVXFknxoNtTK40tgBKlGhnIpz3m6vXxgSi0dcVfaNnLSP b7Q7mC4g0wnsJ/XJ5ODO/v88+2ywJjGjY1Sm7peB2hrPStA9rELj9nAZbaDYKNnT/wn4 eJog+ER09jN4JiueCOQvMOUhrE5QqW7lAJheX2OvgvXjiyL3BYRN+1el+72svFaVXzn2 hVwG1KpTvMJTNz7Zm/HoNORmpEOIgBUjuN8zWWXq8Fuv0YuZWAxRLlPNHWMs61Lz6emg 8MNA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o30si3310996pgb.230.2021.10.08.08.03.18; Fri, 08 Oct 2021 08:03:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242782AbhJHPDh (ORCPT + 99 others); Fri, 8 Oct 2021 11:03:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54508 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237929AbhJHPDg (ORCPT ); Fri, 8 Oct 2021 11:03:36 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 41C89C061570; Fri, 8 Oct 2021 08:01:41 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: andrzej.p) with ESMTPSA id A4F701F45ABA Subject: Re: [PATCH 0/2] media: rkvdec: Align decoder behavior with Hantro and Cedrus To: Chen-Yu Tsai , Ezequiel Garcia , Mauro Carvalho Chehab Cc: linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org, Greg Kroah-Hartman References: <20211008100423.739462-1-wenst@chromium.org> From: Andrzej Pietrasiewicz Message-ID: Date: Fri, 8 Oct 2021 17:01:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20211008100423.739462-1-wenst@chromium.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Chen-Yu Tsai, W dniu 08.10.2021 o 12:04, Chen-Yu Tsai pisze: > Hi everyone, > > While working on the rkvdec H.264 decoder for ChromeOS, I noticed some > behavioral differences compared to Hantro and Cedrus: > > 1. The driver always overrides the sizeimage setting given by userspace > for the output format. This results in insufficient buffer space when > running the ChromeOS video_decode_accelerator_tests test program, > likely due to a small initial resolution followed by dynamic > resolution change. > > 2. Doesn't support dynamic resolution change. > > This small series fixes both and aligns the behavior with the other two > stateless decoder drivers. This was tested on the downstream ChromeOS > 5.10 kernel with ChromeOS. Also compiled tested on mainline but I don't > have any other RK3399 devices set up to test video stuff, so testing > would be very much appreciated. > > Also, I'm not sure if user applications are required to check the value > of sizeimage upon S_FMT return. If the value is different or too small, > what can the application do besides fail? AFAICT it can't split the > data of one frame (or slice) between different buffers. > > Andrzej, I believe the second patch would conflict with your VP9 series. > The conflict is rather trivial to solve. Adopting your version does not change in any way (neither for better nor for worse) the fluster score I get for vp9 with rkvdec on a rockpi4 using my vp9 series. Regards, Andrzej > > Regards > ChenYu > > Chen-Yu Tsai (2): > media: rkvdec: Do not override sizeimage for output format > media: rkvdec: Support dynamic resolution changes > > drivers/staging/media/rkvdec/rkvdec-h264.c | 5 +-- > drivers/staging/media/rkvdec/rkvdec.c | 40 +++++++++++----------- > 2 files changed, 23 insertions(+), 22 deletions(-) >