From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 0068345EE6 for ; Wed, 16 Aug 2023 07:55:32 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id BCD7268C4E4; Wed, 16 Aug 2023 10:55:29 +0300 (EEST) Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.120]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 3180C68C2BF for ; Wed, 16 Aug 2023 10:55:21 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1692172527; x=1723708527; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=tyUdtWeIrz59PcHA38GUx4gjSpQcUjGqiBwSNWpg8wM=; b=f3EQJI/ZC3lQL4c+M2fRqPBA/hLDu8+/b0EjSnwIPt1kfTZmzTGXMRnh Cx3aQ6xJLFdBAdzMbSXC73xOzkh2gox1E1hLKFINBO9hiec1N1K04qYdv 0FUybvp8BUU6/A9dMcPhGCCsGvUWt0tNzIA+UYKIaIwkoBsg5V6yFKEyz 5ieW7xn+t4omjM5TNhnBAoMidjTVA0qGJNdaojlpYIg5+6CTMrH0+KSal SLuDqGAgz80osQmi5vLG/gDW+4qqEkql62T1YeS4benkzvaaH/vjSmOJz 3nvqhy0fzvCCK8RHE7Kms8E20v4//eDb+OJqVrp9Uo6/bV42Tw2IzEqf1 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10803"; a="371376290" X-IronPort-AV: E=Sophos;i="6.01,176,1684825200"; d="scan'208";a="371376290" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Aug 2023 00:54:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10803"; a="799481774" X-IronPort-AV: E=Sophos;i="6.01,176,1684825200"; d="scan'208";a="799481774" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by fmsmga008.fm.intel.com with ESMTP; 16 Aug 2023 00:54:59 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Wed, 16 Aug 2023 00:54:59 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Wed, 16 Aug 2023 00:54:59 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27 via Frontend Transport; Wed, 16 Aug 2023 00:54:59 -0700 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.47) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.27; Wed, 16 Aug 2023 00:54:58 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Za4Dhhf1siZSyDLh7Wdg0QsxgwtVpE0JpficxL/isMhCVV182bqqC6K5v/zLl5y2/dJFBg1bSiHNX25oumtBN0vUhGnvmGEDkXmi/CIzN4CxqC/sYi0yyBG8YUXUl6YjxJvuu0wBUFJzzIZwyvcN7ahFrQqdsKYs44gDCmEwQN3FplRvgPcV2KHLyu9qpQsnWvBZLjciMPDZ6ZId/2K9RBHMNnHHBNLXF++yT/b2knQhPTxYVKQdMqCW9dFrL+i9cqITaGTAqjBXAqodZurErGY9GjbIXJ0C5jWSvR7bTiVHJgBXDAz8J5PQOdFtk3f+mOxfj5GXhmmYLUeJts2zBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tyUdtWeIrz59PcHA38GUx4gjSpQcUjGqiBwSNWpg8wM=; b=aKvBUCKTR0Kwalvxkjbl1sD/fD/Ylv4gSGzk0Y6DtF3kVO6O3ODfzb/SBu1cUCLaadupbX6bgVxoCBDedZ06AuprEVm4lnhoe2x/GjJLUiq607kr2ldPFwNIK49tl9Oicms68AZQM5w9eIUtO46JQlKnfVFqKSxwXkjwaM+ixYZ/jfYv6yV+v855WNcCCsRPaOOwJ4qbJbpZfNcHlpDG7wEO87MAfzQOL58OHQdi7+ZXLBj8UeG4upEjWZpUTbmjAZjjU/n2Tp+0Lfz/DdHRwW/sqmL6hKEmNrcWfhktKm+NjXmbMumvI/lag4Q9Oh9Dismfnm4FsMwlNESpnG7leQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from PH0PR11MB5030.namprd11.prod.outlook.com (2603:10b6:510:41::5) by IA1PR11MB6121.namprd11.prod.outlook.com (2603:10b6:208:3ef::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6678.26; Wed, 16 Aug 2023 07:54:51 +0000 Received: from PH0PR11MB5030.namprd11.prod.outlook.com ([fe80::77e2:c7a3:f37c:2a41]) by PH0PR11MB5030.namprd11.prod.outlook.com ([fe80::77e2:c7a3:f37c:2a41%4]) with mapi id 15.20.6678.029; Wed, 16 Aug 2023 07:54:51 +0000 From: "Wang, Fei W" To: "ffmpeg-devel@ffmpeg.org" Thread-Topic: [FFmpeg-devel] [PATCH v3 6/6] lavc/vaapi_encode: Add VAAPI AV1 encoder Thread-Index: AQHZyXU4zrC4trJyMkGxDqpyoE2RhK/i2SOAgAXydwCAA89LAA== Date: Wed, 16 Aug 2023 07:54:51 +0000 Message-ID: References: <20230803060132.501741-1-fei.w.wang@intel.com> <20230803060132.501741-6-fei.w.wang@intel.com> <336d0b1463430f3591a9444b60191cf00f595700.camel@intel.com> <1acd766d-e0dc-69f6-56e5-0d84e62f83c8@jkqxz.net> In-Reply-To: <1acd766d-e0dc-69f6-56e5-0d84e62f83c8@jkqxz.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Evolution 3.36.5-0ubuntu1 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PH0PR11MB5030:EE_|IA1PR11MB6121:EE_ x-ms-office365-filtering-correlation-id: c553128d-3673-4e14-1595-08db9e2e1250 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: E9B9qR793d0nhHclsA5YlohfFaQd5bzvS9H51Dc+ijXpvl8lR/cBrHK3QRaEv4g0Q20rKfxkByqEirz0ODFR/X8W5H75CBaFmWq+lXE+3eY4c14oZV3gMnjdKKpDywfz45t1zQRnxb2tsdVv2S3tGQ0e7I/sSBk3u9GnLWPAxyhpxd5LpEw15Iy/7OU+MR9eGxuaLxpna7RFBheg/A+5aL+UUq2JuM6nZKslNI8cwauRam0mX/nyHWIYdS6n7OPeaMTdumao8Ne1o0ycxl5gibF9cm9Yn8Pnm5saz107xtglVr4rqY/I41FToY+qrWt4eyU5CH8GebUE/syySQz7gFHzfPlLeaC17lXcY/yyn9OdQCYFW/IIrHdzHer/DQc1buIwPGoYLnBK3ZN9MngW8r3JfiMbuKVkM2hcaNUOf13HLt0bteGpujfx50AoQF7OEC2QU8/QqM7BmCosIxT+yv54KMSulKsf7/c3/PdU30cG3/dstu39Y3RsuOgd+o+e4Tg+Sg/XWRS+cOEfEp+Ylb4/1WDPozlgwtbJuIrRSGQ8FVjRKhLBMuIjcKmpXkw+ssS70eposBzIQYdVDlBEFGzm/ptRL59NI1I+6a9QF8weXi1S2FtbKeK4xFaJiI7U x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5030.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376002)(366004)(39860400002)(396003)(346002)(136003)(1800799009)(451199024)(186009)(71200400001)(64756008)(66446008)(76116006)(66476007)(66556008)(66946007)(6512007)(6486002)(6506007)(19627235002)(30864003)(2906002)(478600001)(966005)(26005)(91956017)(6916009)(5660300002)(2616005)(83380400001)(41300700001)(316002)(53546011)(8936002)(8676002)(66899024)(122000001)(38100700002)(38070700005)(82960400001)(36756003)(86362001)(21314003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Q1dGMFFMSU1jeG1Cdm5kWXZ0SWg3M0MxYVRLTnpYR25aRCtNa1FwVWc3T0Ir?= =?utf-8?B?enlKaW1jV25ORTNRRFR5Q2RuTGhMZmxjWWxZbHBJaSsydGljeUY5ZVp6YkRh?= =?utf-8?B?bFJkeCs1RndJZVdFRVRycm1HV0Fsdnh5Z1NtLzhuY2FsaEhVTmNlckt6WC9V?= =?utf-8?B?SHpCRW0vSDgzc3V5M1lFcS8vZlRjdFEwWGNvMG9uS0g5MGVoUzhsUjJNcEZD?= =?utf-8?B?eEQ0RVFsbFpHSTdKMkdYZEZ0WnhLSzVPUzQxKzVLTEZ0WVd3YnhDSm1iMmZD?= =?utf-8?B?cnJwR01jalB6bDdhT1JOR2lTUERkSUM2R0ZKbE5LWVh2N0tpeDdrV05JZkN5?= =?utf-8?B?ZllOeFdlN3hvNTJzN1EvaGRhTTdEVDlaUHIyN3pXSlRzZXc1eUEzemFRL3ln?= =?utf-8?B?Wlk0dmNwVHhNaVJ1cDZIb1gyS29BQ05hb1c0Z1dMU3h0R3NKUjRTcStZaHEx?= =?utf-8?B?dHVGWjRRVnl3b3FWNWl0NXJTQ2ZIV1lhYVFWaDZHTWVaVGRWTll3TnUwZXpv?= =?utf-8?B?TlpRUWZaR0YrWWVROXI4QjdlMmRtK1ZlRlJOa2M5UHZncmhpelN3RDVCN0hH?= =?utf-8?B?WHlUNzBLQkZMKzRvREswZDBsaG81NkVLWnBVR1krMzQyQVdQdEczS0F6Nnpi?= =?utf-8?B?M0d6dHFQYmxwQ2s5N29USFd3Ty9FUFY4K0xkMGdYaUZJYndZcml2QUp3TytR?= =?utf-8?B?OW5KbEJHU3I4aHVWbFdLMzZTU3JVbkFwaUNrLytXclNhZHp5M2E5V0VobnlG?= =?utf-8?B?SGplQ0I5SUswUEtmYnp6b3QyOElQVmM5THgrZEhsUEJoRDh0Ky9yNkVoMDRl?= =?utf-8?B?a1hrRFpvU1oybUh1UVkyeXBhNUxUT05vazlxNjU5NzA0MGMzTlh3amRMV3Nj?= =?utf-8?B?NC96dXZDYmlJRGRhSjlkcm9nOG9NczJVR1VLekY0TnlHMXJhYmJWUW9rS0h5?= =?utf-8?B?TXhhb25xR3J4MFZteWVGejZSZXNGcWUwYzdPTDFxbDNLcWFUM2x2S3VyRWNV?= =?utf-8?B?TFFmTm9ScWNzSmxibVBTM0JsYURmYTNzRlNlUEVhT3JLY1E2c2xURkpCeHpz?= =?utf-8?B?WmpMNE51QXVTdWdaTUFhV2hjMWkwaXRDYVZTRVIzRnM5VWE4TlZvcGFUa2hO?= =?utf-8?B?cVh5SmJTUVlPOVA2UG0vODJCQjBWKzBkWmkyNTE2UjBUTXdlTm9IRm1rRXQy?= =?utf-8?B?Nm8zdGZpbjdlR3RENHNUOXhEdDRzREc3OFl4NFFlK041S2dOQXpVQ3ZBckhT?= =?utf-8?B?UlcwTGttNnpMbEM3amlydEtMV0tZQ3MybVVRM1F3Yk9LMExsV0ExTE5SVGF2?= =?utf-8?B?MXFydTlORmdsTW1jZXlSSXA4NTRqU05OalNyczM4ekZIKzVZWGt5b0F1a3gr?= =?utf-8?B?dFYyVXZwZDhHVEN2ZkhSU29jSnNTYm9OcEd6RlFJVGgxdVQrdW5kWk9RNXVG?= =?utf-8?B?UlJ4Z20vRVJFWTExallTdWJkNEszVERtQStuSWJVbGZjd3ZERS9sdlFHelRY?= =?utf-8?B?eU5yUVdMMVJWTVcydFNKanp3cmQ1SzZlU29uU1dLVGk3aWFBTjNtdjBLU1FK?= =?utf-8?B?MXRmTEs5QXkrOW9BZ2RVMFhuV09tc04wU0tsRVRnN2VSWk1YMmw5ekFLanpW?= =?utf-8?B?RnpFU2ozTUxOQlVCNmVDVU0rY0NDQSsycXhQYmRKdVRlZWJnbEE5cU5vN3Vn?= =?utf-8?B?VU5YSjU1b05PREVqMlVhSDBpWWRKL01lZERMeHVVd1BBbVRMVnV3NTYrbmFs?= =?utf-8?B?Qmgwcy95dDVvS0lYa2Y2d3M5R1A4Tk1ndWVqSDZHWUw1NUZ5bkVPejl3c0Ir?= =?utf-8?B?cXdXaGtyQlY2YXBHZnJ1RmdUcHlzRnIwUmNabnd6OHd5NENVdXV2bTVqTUFp?= =?utf-8?B?WDhNOVZabE1VVExCbDg1U0RyUkYwN0RoZTFHL0tqbDh0UDF5eFluWE4wbVFj?= =?utf-8?B?R2VhTDAzSXNEaHBTZ2hhWDJpTU9laEtSaThBVllxRVNydjBOUXdUdW5EeG16?= =?utf-8?B?eVpQNnZPOExzTEIzRTd6MUlmZm5FbWY0dEV2V2t2MUt0NGpPd0QzQkJTRExk?= =?utf-8?B?N01FT2Y5VDBSbEZGTit6YnVxSEZFRGcweXBWTWpqVVJka2hOTHI1WVRHaW5X?= =?utf-8?Q?Vhgdapr74DiUZmnodsVdAExu7?= Content-ID: MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5030.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c553128d-3673-4e14-1595-08db9e2e1250 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2023 07:54:51.5552 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1hiybX3bLUexbXG54I3NqBiI+fKkHzwUxcQF8hlSLDUOaW+Lf9b2HYnkYy7/h6Bpj1iqPW0Q0o4p0sJ6bwe8iQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR11MB6121 X-OriginatorOrg: intel.com Subject: Re: [FFmpeg-devel] [PATCH v3 6/6] lavc/vaapi_encode: Add VAAPI AV1 encoder X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Sun, 2023-08-13 at 22:43 +0100, Mark Thompson wrote: > On 10/08/2023 03:54, Wang, Fei W wrote: > > On Mon, 2023-08-07 at 22:21 +0100, Mark Thompson wrote: > > > On 03/08/2023 07:01, fei.w.wang-at-intel.com@ffmpeg.org wrote: > > > > From: Fei Wang > > > > > > > > Signed-off-by: Fei Wang > > > > --- > > > > Changelog | 1 + > > > > configure | 3 + > > > > doc/encoders.texi | 13 + > > > > libavcodec/Makefile | 1 + > > > > libavcodec/allcodecs.c | 1 + > > > > libavcodec/vaapi_encode.c | 125 +++- > > > > libavcodec/vaapi_encode.h | 12 + > > > > libavcodec/vaapi_encode_av1.c | 1229 > > > > +++++++++++++++++++++++++++++++++ > > > > libavcodec/version.h | 2 +- > > > > 9 files changed, 1368 insertions(+), 19 deletions(-) > > > > create mode 100644 libavcodec/vaapi_encode_av1.c > > > > > > I assume this is tested on Intel hardware. Is it tested on AMD > > > as > > > well? (Apparently working in recent Mesa.) > > > > AMD tested the patchset months ago: > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22585 > > > > This patch changed a little compare with the version in Cartwheel, > > @Ruijing, Could you help to review this version in ML? To avoid the > > diffs break you. Thanks. > > > > > > ... > > > > @@ -669,6 +669,15 @@ static int > > > > vaapi_encode_set_output_timestamp(AVCodecContext *avctx, > > > > { > > > > VAAPIEncodeContext *ctx = avctx->priv_data; > > > > > > > > + // AV1 packs P frame and next B frame into one pkt, and > > > > uses > > > > the other > > > > + // repeat frame header pkt at the display order position > > > > of > > > > the P frame > > > > + // to indicate its frame index. Each frame has a > > > > corresponding > > > > pkt in its > > > > + // display order position. So don't need to consider delay > > > > for > > > > AV1 timestamp. > > > > + if (avctx->codec_id == AV_CODEC_ID_AV1) { > > > > + pkt->dts = pkt->pts - ctx->dts_pts_diff; > > > > + return 0; > > > > + } > > > > > > This doesn't get you the right result, though? The PTS and DTS > > > on > > > every AV1 packet want to be the same. > > > > The result tested good which can be played normally. Just aligned > > with > > other vaapi encoders that the 1st frame start with 0/-1 of PTS/DTS > > if > > have B frame. Set PTS/DTS to same also looks good. > > DTS != PTS should only be true when the stream has externally-visible > frame reordering in, which AV1 doesn't. > > The other two AV1 encoders both output DTS == PTS; I think you should > match that. > > > > In any case, please don't put tests for codec ID in the common > > > code. I suggest that the timestamp behaviour wants to be a new > > > FLAG_*. > > > > > > > + > > > > ... > > > > @@ -1128,9 +1182,19 @@ static int > > > > vaapi_encode_pick_next(AVCodecContext *avctx, > > > > > > > > vaapi_encode_add_ref(avctx, pic, pic, 0, 1, 0); > > > > if (pic->type != PICTURE_TYPE_IDR) { > > > > - vaapi_encode_add_ref(avctx, pic, start, > > > > - pic->type == PICTURE_TYPE_P, > > > > - b_counter > 0, 0); > > > > + // TODO: apply both previous and forward multi > > > > reference > > > > for all vaapi encoders. > > > > + // And L0/L1 reference frame number can be set > > > > dynamically > > > > through query > > > > + // VAConfigAttribEncMaxRefFrames attribute. > > > > + if (avctx->codec_id == AV_CODEC_ID_AV1) { > > > > + for (i = 0; i < ctx->nb_next_prev; i++) > > > > + vaapi_encode_add_ref(avctx, pic, ctx- > > > > > next_prev[i], > > > > + pic->type == > > > > PICTURE_TYPE_P, > > > > + b_counter > 0, 0); > > > > > > So an undisclosed aim of the previous patch was to make this > > > extra > > > list of the most recent N frames for this to use with P frames > > > only? > > > > Currently, yes. As the TODO comment says, I will apply it to all > > other > > codecs and B frame next, it will need lots of test on different > > hardware. Add this for AV1 here is to align with VPL which use 2 > > previous reference for P frame. Base on our test, 2 reference frame > > for > > P will improve ~5% BD-rate for quality, so that can make it > > possible to > > let user get same quality with VPL after adjusting and aligning > > encoder > > options. > > Hmm. My Intel test machine says it can take 8 L0 and 2 L1 references > in H.264. I might try this, seems like it should be easy to test. Yes, if L0/L1 number queried from driver are fully supported, need to increase MAX_PICTURE_REFERENCES and init size of surface pool. > > > > Why this partcular structure for P frames only, though? Seems > > > like > > > if you support extra references then other codecs could also make > > > use > > > of them in either direction, so we would be better off hinting > > > that > > > the codec would like up to N references and then using the > > > contents > > > of the existing DPB, plus keep extras if there is space. > > > > > > > ... > > > > + > > > > +static av_cold int vaapi_encode_av1_configure(AVCodecContext > > > > *avctx) > > > > +{ > > > > + VAAPIEncodeContext *ctx = avctx->priv_data; > > > > + VAAPIEncodeAV1Context *priv = avctx->priv_data; > > > > + int ret; > > > > + > > > > + ret = ff_cbs_init(&priv->cbc, AV_CODEC_ID_AV1, avctx); > > > > + if (ret < 0) > > > > + return ret; > > > > + > > > > + if (ctx->rc_mode->quality) { > > > > + priv->q_idx_p = av_clip(ctx->rc_quality, 0, > > > > AV1_MAX_QUANT); > > > > + if (fabs(avctx->i_quant_factor) > 0.0) > > > > + priv->q_idx_idr = > > > > + av_clip((fabs(avctx->i_quant_factor) * priv- > > > > > q_idx_p + > > > > + avctx->i_quant_offset) + 0.5, > > > > + 0, AV1_MAX_QUANT); > > > > + else > > > > + priv->q_idx_idr = priv->q_idx_p; > > > > + > > > > + if (fabs(avctx->b_quant_factor) > 0.0) > > > > + priv->q_idx_b = > > > > + av_clip((fabs(avctx->b_quant_factor) * priv- > > > > > q_idx_p + > > > > + avctx->b_quant_offset) + 0.5, > > > > + 0, AV1_MAX_QUANT); > > > > + else > > > > + priv->q_idx_b = priv->q_idx_p; > > > > + } else { > > > > + /** Arbitrary value */ > > > > + priv->q_idx_idr = priv->q_idx_p = priv->q_idx_b = 128; > > > > + } > > > > > > Are there any alignment requirements here? (If I gave it an > > > input > > > which is, say, 1361x1, would that work?) > > > > I didn't get you. Which parameter here need to be align? Max/Min > > resolution HW supported will be checked somewhere else. If use > > 1361x1 > > there will be the error like: > > > > "Hardware does not support encoding at size 1376x16 (constraints: > > width > > 32-8192 height 32-8192)." > > I mean of padding for the reference surfaces. I was expecting this > to be rounded up to a multiple of 8 (to match MiCols/MiRows) - see > this function in other codecs. > > > > > ... > > > > + > > > > + /** update obu size in bitstream */ > > > > + if (fh_obu->header.obu_has_size_field) { > > > > + obu_size_len = priv- > > > > >attr_ext2.bits.obu_size_bytes_minus1 > > > > + 1; > > > > + for (i = 0; i < obu_size_len; i++) { > > > > + byte = obu_size >> (7 * i) & 0x7f; > > > > + if (i < obu_size_len - 1) > > > > + byte |= 0x80; > > > > + put_bits(&pbc_tmp, 8, byte); > > > > + } > > > > + flush_put_bits(&pbc_tmp); > > > > + memmove(pbc_tmp.buf_ptr, pbc_tmp.buf_ptr + (8 - > > > > obu_size_len), obu_size); > > > > + *data_len -= (8 - obu_size_len) * 8; > > > > + } > > > > > > Why is there an incomplete duplicate of the cbs_av1 header > > > writing > > > code here? > > > > To record some position/size in bitstream that needed for VAAPI. > > Like > > qp_index/loopfilter/cdef offset and cdef parameters size in bit. > > It's > > not reasonable to add the specific parameters into CBS. > > How about with < > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-August/313228.html> > ;? How to pass position info out of .trace_write_callback? If define own write_callback function in vaapi_encode_av1.c, and it can easily get the positions of each syntax element, but can't pass them back to VAAPI AV1 encoder. A possible way is according to CodedBitstreamContext.priv_data, but that will need to add lots of xxx_offset into CodedBitstreamAV1Context. > > > > > ... > > > > + > > > > +static int vaapi_encode_av1_set_tile(AVCodecContext *avctx) > > > > +{ > > > > + VAAPIEncodeAV1Context *priv = avctx->priv_data; > > > > + int mi_cols, mi_rows, sb_shift, sb_size; > > > > + int max_tile_area_sb, max_tile_area_sb_varied; > > > > + int tile_width_sb, tile_height_sb, widest_tile_sb; > > > > + int min_log2_tiles; > > > > + int tile_rows_tmp, i; > > > > + > > > > + if (priv->tile_cols > AV1_MAX_TILE_COLS || > > > > + priv->tile_rows > AV1_MAX_TILE_ROWS) { > > > > + av_log(avctx, AV_LOG_ERROR, "Invalid tile number > > > > %dx%d, > > > > should less than %dx%d.\n", > > > > + priv->tile_cols, priv->tile_rows, > > > > AV1_MAX_TILE_COLS, AV1_MAX_TILE_ROWS); > > > > > > Can't this be a constraint on the option rather than a special > > > check > > > here? > > > > Tiles set with IMAGE_SIZE option type which aligns with HEVC. It > > doesn't support Min/MAX check. > > Hmm, yeah - fair enough. > > > > > ... > > > > + > > > > + sh->color_config = (AV1RawColorConfig) { > > > > + .high_bitdepth = desc->comp[0].depth > > > > == 8 > > > > ? 0 : 1, > > > > + .color_primaries = avctx- > > > > >color_primaries, > > > > + .transfer_characteristics = avctx->color_trc, > > > > + .matrix_coefficients = avctx->colorspace, > > > > + .color_description_present_flag = (avctx- > > > > >color_primaries > > > > != AVCOL_PRI_UNSPECIFIED || > > > > + avctx- > > > > > color_trc != AVCOL_TRC_UNSPECIFIED || > > > > + avctx- > > > > > colorspace != AVCOL_SPC_UNSPECIFIED), > > > > + .color_range = avctx->color_range > > > > == > > > > AVCOL_RANGE_JPEG, > > > > + .subsampling_x = desc->log2_chroma_w, > > > > + .subsampling_y = desc->log2_chroma_h, > > > > > > .chroma_sample_position = some function of > > > chroma_sample_location. > > > > There is no chroma_sample_position supported in VAAPI yet. > > VAAPI won't care. It should be marked correctly in the headers so > that the output stream has the right value. > > (CFL not having any ability to deal with the sample location is a > known deficiency of AV1.) > > > > > ... > > > > + fh->tile_cols = priv->tile_cols; > > > > + fh->tile_rows = priv->tile_rows; > > > > + fh->tile_cols_log2 = priv->tile_cols_log2; > > > > + fh->tile_rows_log2 = priv->tile_rows_log2; > > > > + fh->uniform_tile_spacing_flag = priv->uniform_tile; > > > > + fh->tile_size_bytes_minus1 = priv- > > > > > attr_ext2.bits.tile_size_bytes_minus1; > > > > + fh->reduced_tx_set = 1; > > > > > > This not being present in the capabilities feels like an omission > > > in > > > the API. That's a large loss for an implementation which does > > > support the full transform set. > > > > Personally understanding, "not being present" means it must be > > supported. If any exception driver, then they can ask to add new > > capability to libva. > > reduced_tx_set is a negative property - you want to set it to zero to > allow all transforms, unless the implementation can't cope with that. > > Does the Intel implementation require it to be set? (That is, does > not support the full transform set.) > That make sense. Intel HW doesn't require it to be set as 1. Will change it to 0. > > > > ... > > > > + > > > > + for (i = 0; i < fh->tile_cols; i++) > > > > + fh->width_in_sbs_minus_1[i] = vpic- > > > > > width_in_sbs_minus_1[i] = priv->width_in_sbs_minus_1[i]; > > > > + > > > > + for (i = 0; i < fh->tile_rows; i++) > > > > + fh->height_in_sbs_minus_1[i] = vpic- > > > > > height_in_sbs_minus_1[i] = priv->height_in_sbs_minus_1[i]; > > > > > > Er, what? Doesn't this fail the inference on the last tile > > > width/height if you don't split exactly? > > > > What's the meaning of "split exactly"? All the tile w/h will be > > split > > in vaapi_encode_av1_set_tile include last tile. Just make sure the > > info > > of tiles w/h in frame header are same with the info passed to VAAPI > > should be fine. > > Sorry, I misread this. The values are set elsewhere, it's not > setting all tiles to have the same SB width/height. > > > > > ... > > > > + > > > > + vpic->base_qindex = fh->base_q_idx; > > > > + vpic->frame_width_minus_1 = fh->frame_width_minus_1; > > > > + vpic->frame_height_minus_1 = fh->frame_height_minus_1; > > > > + vpic->primary_ref_frame = fh->primary_ref_frame; > > > > + vpic->reconstructed_frame = pic->recon_surface; > > > > + vpic->coded_buf = pic->output_buffer; > > > > + vpic->tile_cols = fh->tile_cols; > > > > + vpic->tile_rows = fh->tile_rows; > > > > + vpic->order_hint = fh->order_hint; > > > > +#if VA_CHECK_VERSION(1, 15, 0) > > > > + vpic->refresh_frame_flags = fh->refresh_frame_flags; > > > > +#endif > > > > > > What will the difference be between running in the two > > > versions? (Is > > > it worth supporting the older one? Cf. bit_depth on VP9.) > > > > I'd prefer to support older one. In case of someone using old > > version > > and works well with ffmpeg-vpl(as vpl already support av1 encode > > long > > time ago), otherwise he must be confuse why ffmpeg-vaapi need > > higher > > VAAPI version but VPL doesn't. > > Ok. So the driver doesn't use the value of refresh_frame_flags if it > doesn't affect the result? (Seems like it shouldn't, not sure why it > would be added to the API.) Media-driver doesn't use it, but MS Windows driver does, it may need maintain DPB and pack frame header itself: https://github.com/intel/cartwheel-ffmpeg/issues/244 Thanks > > > > > ... > > Thanks, > > - Mark > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".