Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp5869865pxb; Mon, 14 Feb 2022 09:25:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJzmjfhu3mnwXY2XiP+Aep/tdjZOwsdOI68rNsI9dht9LT29U7WjcX5Xw65ylNuaxssba0A/ X-Received: by 2002:a17:902:d502:: with SMTP id b2mr691104plg.154.1644859533811; Mon, 14 Feb 2022 09:25:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644859533; cv=none; d=google.com; s=arc-20160816; b=Wkgq8jIub6W0ZAZYZryihXgQC54PYsgEqOA0XJXBzh8ax5UF/sDwd1NCRRlyUe3aUw UrYn37zctPpmbYOPvWpq5Q+OJikGuxkExNT4HlOFbnOWdyaJZzO1ef/wDeb+qyuBUnX3 bvoWFszz6CrF+/yu5zKzauZEivgwJgAxJU/GVfS4m48jDlSj80DJNfpUFkBGZW36BYAl iQa0NBl40kOauCSJHmR7E/VtAYB16+s1P/0RjYKs3WEuv8fesYnvNFohW5gVRwCwWCXu 7EfjcqusFLyaXcrgU6Y6nGKV5FVOZCWeAQLHlI+d37jGqB2cC0ymQ9uWk8HRXK1U1cVJ G2Lg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=OMl/IbSY4aUP2ApqdeD2ydzp7Fr7kOTZNUbiTtyO1cU=; b=AzM5DRaEoZjF0yGQiRnpP8YDzxTu4/KS3/sqMWYce46aABsLRtIAAOCKiuSBl4Apvm ohSUHRZhssLNqSUE5rfYlrhkv0HFAZxfbzJDqyzQylZlYk27EgCLGgnM9MxdyhVzAbx2 3VySU+IYEcakU4LEApx0TYYFzHMfaya8qIp0K/YQZpevH3+0cFPzciQRBcG/LOjhEq+D QwGve43/qXGRmIdl605qDcPw9tO96g3zThK8elodxzpdBkPNv1tmKDId+EsSvrOo7Xa0 K85sjOI9cilCtzXxbQ2M5+2BGs7MP8Oenk46/DRZgE1vmrECwt4wG1lVFb7PXMrbP65A ghCA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xs4all.nl Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e2si12093290plj.305.2022.02.14.09.25.15; Mon, 14 Feb 2022 09:25:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xs4all.nl Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348669AbiBNKiF (ORCPT + 99 others); Mon, 14 Feb 2022 05:38:05 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:41876 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348352AbiBNKes (ORCPT ); Mon, 14 Feb 2022 05:34:48 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 151B01164; Mon, 14 Feb 2022 02:01:44 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id AFF79B80DC8; Mon, 14 Feb 2022 10:01:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2CF7BC340E9; Mon, 14 Feb 2022 10:01:38 +0000 (UTC) Message-ID: <713cee9b-c96c-119a-65be-3c289b361915@xs4all.nl> Date: Mon, 14 Feb 2022 11:01:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [RFC] media: uapi: Move HEVC stateless controls out of staging Content-Language: en-US To: =?UTF-8?Q?Jernej_=c5=a0krabec?= , mchehab@kernel.org, ezequiel@vanguardiasur.com.ar, p.zabel@pengutronix.de, gregkh@linuxfoundation.org, mripard@kernel.org, paul.kocialkowski@bootlin.com, wens@csie.org, jonas@kwiboo.se, nicolas@ndufresne.ca, Benjamin Gaignard Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, linux-staging@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, kernel@collabora.com, Alex Bee , jc@kynesim.co.uk References: <20220201123439.353854-1-benjamin.gaignard@collabora.com> <8038233.T7Z3S40VBb@kista> From: Hans Verkuil In-Reply-To: <8038233.T7Z3S40VBb@kista> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,NICE_REPLY_A,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, On 2/13/22 12:33, Jernej Škrabec wrote: > Hi Benjamin, > > CC: Alex, John > > Sorry for late response, but I've been very busy last week. > > First of all, thank you for doing this! It's about time that HEVC moves > forward. > > Dne torek, 01. februar 2022 ob 13:34:39 CET je Benjamin Gaignard napisal(a): >> The HEVC stateless 'uAPI' was staging and marked explicitly in the >> V4L2 specification that it will change and is unstable. >> >> Note that these control IDs were never exported as a public API, >> they were only defined in kernel-local headers (hevc-ctrls.h). >> >> While moving the controls out of staging they are renamed and >> control IDs get new numbers. >> Drivers (Hantro, Cedrus) and Documentation are updated accordaly. > > accordaly -> accordingly > >> >> Additional structures fields has been added for RKVDEC driver usage. > > You should do separate patch for that, preceding this one. One patch should > only do one thing. > > I also suggest that you add additional patch for removing bit_size field in > struct v4l2_ctrl_hevc_slice_params. Similar fields were already removed from > MPEG2 and H264 structures. Bit size can be deduced from output buffer size and > it doesn't hurt if bit size in Cedrus is set to bigger value than actual slice > bit size. > >> Hantro dedicated control is moving to hantro-media.h >> Since hevc-ctrls.h content has been dispatched in others file, remove it. >> >> fluster tests results on IMX8MQ is 77/147 for HEVC codec. >> >> Signed-off-by: Benjamin Gaignard > > Note that Cedrus still needs additional information in order to decode some > HEVC videos. Missing info is num_entry_point_offsets and list of all > entry_point_offset_minus1 (obviously, num_entry_point_offsets in size). > > I suggest that this is represented in a new control, which would use dynamic > array feature, written by Hans. While Cedrus supports max. 256 entries, it can > be much bigger in theory, but in reality, it's much smaller (like 4-8 > entries). I've rebased my dynarray tree, so it is up to date again: https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=dynarray Regards, Hans > > Last but not least, data_bit_offset should be better defined. Currently it > points right after last header bit, just like Cedrus needs it. However, there > is padding after that, at least 1 bit and 8 bits at most, so slice data always > starts from byte aligned address. It probably make sense to rework that field > to be byte offset, not bit, just like in VA-API. Note that RPi HEVC driver also > uses byte aligned address directly. Cedrus would need some kind of workaround > and only one that works is this one: > https://github.com/bootlin/libva-v4l2-request/blob/master/src/h265.c#L191-L209 > > Best regards, > Jernej > >