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 7CACC42918 for ; Mon, 10 Jan 2022 06:47:49 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 462E068A6E0; Mon, 10 Jan 2022 08:47:46 +0200 (EET) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 9F32A68A375 for ; Mon, 10 Jan 2022 08:47:39 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1641797264; x=1673333264; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=QiaaRuuPWaSqjyfuP5Y1iR/ZxiR1IYR4GQUtqg8JLj8=; b=FTdP3O0b3U7SZtz5s96lehLbrYv9+riKx9ReuPTibznOPGpAGDtCkHXm 0Uk/yaXgl39rDlOwTpxFSVIlMHcLNZX6WHXK23+z2SMzfWwIS5zdGfIbU fAC985O6Uh/JqmNbP2UOHNCdx0blGc6p9m5a6ZCn8qJG8g6moXcUqSpj/ lNVeINxw4GKM9eCQ8ou7kYA9sSgdB0OWKMDUxf5sKEGTYhvoZqrOHnN7b y8DeZC40XJj633c06lTCUqL8CmmhWJhF7YTtGDuXshDY/7Sy4f+06toN0 C7eWnl99ICIkJwkPMzE7Cs7lwRKvcN5J3MCaCrbs2Vwpwya26eDGq+mWz Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10222"; a="267488784" X-IronPort-AV: E=Sophos;i="5.88,276,1635231600"; d="scan'208";a="267488784" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jan 2022 22:47:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,276,1635231600"; d="scan'208";a="612764501" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by FMSMGA003.fm.intel.com with ESMTP; 09 Jan 2022 22:47:36 -0800 Received: from fmsmsx605.amr.corp.intel.com (10.18.126.85) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Sun, 9 Jan 2022 22:47:35 -0800 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20 via Frontend Transport; Sun, 9 Jan 2022 22:47:35 -0800 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.170) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.20; Sun, 9 Jan 2022 22:47:35 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OOtc+DbLsp6KAVLC7T9xwzL8WLUIZvhfoPXHtxkiz+adk79ghZg5SERKj7QxggFjFGsAiefW2dg7hQl5Cs/MFIqNUAu1gTwPr1v6sWziH8snAZK3XPhtROBBhNmP/o466OpVPml/kuXBTJOMMpHxIjjy2MBzgQqw0hbuKJCyXLLbs/93WCHN1AFcx7kHMpRPjp2eK/U5jslJfIk1xH1mZAVzyviQKDShPhuZVwdO+tdxthm9trRD0JBuvc8F19IPNyWvRjuHt0KMHSQY+pYTCCpoSV7+Seukvsq8Pp19IPaX9QGqKd5q9L9Acdsq9HCe4Z6UbRbjHGdY2u4IGsw7/w== 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=QiaaRuuPWaSqjyfuP5Y1iR/ZxiR1IYR4GQUtqg8JLj8=; b=BD3gXUIobkCb7FL25QwQ3kNf3JV+tA2O6P2TM8/Bs+DZacRH344RMFXZ7MXGBrdbkALs+LuGaUzs+HXdBRHGUUZ8ET26qatWTWlFPWRrPDWYqJ+6wsFa/vyo+88PQYFaDylnUimU4Us01Um3Pll+4Q5V/8mOCQcF+blhvT2jECJyQM0cEwGTXoG1QQcB/b9gQO3LOnabOTzZIVsiZ26EiAqIZN+qZai+/W2L8FBGl+/l6x/D8OmgTOIp/5l/t107CnLu8K8SLDXyB0AbBVl1vtXBMPBhDQCLQ6fk4Ts2tM5VYIvPDtbAofyC4dRiQTI5Ej9oc12oJ6NfvgIoiba8Ew== 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 BN9PR11MB5515.namprd11.prod.outlook.com (2603:10b6:408:104::8) by BN6PR11MB1411.namprd11.prod.outlook.com (2603:10b6:404:3c::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4867.7; Mon, 10 Jan 2022 06:47:33 +0000 Received: from BN9PR11MB5515.namprd11.prod.outlook.com ([fe80::d436:c6ab:6e71:8843]) by BN9PR11MB5515.namprd11.prod.outlook.com ([fe80::d436:c6ab:6e71:8843%6]) with mapi id 15.20.4867.011; Mon, 10 Jan 2022 06:47:33 +0000 From: "Xiang, Haihao" To: "ffmpeg-devel@ffmpeg.org" Thread-Topic: [FFmpeg-devel] [PATCH v4 1/1] avutils/hwcontext: When deriving a hwdevice, search for existing device in both directions Thread-Index: AQHX4hsioJyM1GLeREaoFRgSTTytDawV/YDXgAAxacqAAASjAIAqE1oAgAWS44CADigVgIAABTeAgAdFDoCAACuzAIAAIMQAgAAGvYCAABZQgIAADDaAgABVy4A= Date: Mon, 10 Jan 2022 06:47:33 +0000 Message-ID: References: <163785839519.25323.16303122737288435026@lain.red.khirnov.net> <163794332023.25323.7446601680884381987@lain.red.khirnov.net> <163795393240.7822.9483345286843818669@lain.red.khirnov.net> <50841f8a73c902d3fca896b1eda923d082b27383.camel@intel.com> <6c1f517dad96d2d6075cb69a30e1a50aefd3feb9.camel@intel.com> <1379ae9c-d8f9-7e32-260f-eff79ac1cfd7@gmail.com> <6cc00dffb915619af857283b9fb503e7aaeeb603.camel@intel.com> <595cea3f-43d1-e1fb-8541-c620cfd47090@jkqxz.net> <97ce0944-17bc-6e89-160a-e103b77db861@jkqxz.net> In-Reply-To: Accept-Language: en-AS, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c123549a-a62d-4c79-40bf-08d9d40514b0 x-ms-traffictypediagnostic: BN6PR11MB1411:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1l1Z6M+zMbpJdBYEzXEC/y7XOv1UUZgypwUIcyJ2J03WXxV6TCHFv5Hmwj9Nwns948b1fdhVwFSiDn7TYOHO1Wm6Wd6FvNsOjIsyaLiFuVbXzOPbWVDqEm50kJDDjNf63J5tro5lPaunbxBiDA7PA2X+nkJbGQ27Z95iDRigjW5AqmbWVNMAgXoF7bW//+1fHT0DQQrJ1XGfWI8wfYctBsmUhT4z/jXW90LEEaxE9ScvU69GunoYDxUmxJ/y51WgniQUvbh086EgOgP192Klq8sFeG4aMKTlmNEz2TU9ZTn7mJtTnSi/6z5/jt736vXHTMbong3kpdBV/F2DL9yxPYNZ2ztvY7Y4CLx7b1/jmzmQe9k7l+Bus4KLiLyTgx5Y0mydOrDAg7aTiHOmHFwPvjsReva8fWq0z5cq0cCOumrakYQ8zFvbADjmBdQdmyDUsKPmqom4bigsck2Qand2iXXFR+kohCef5tMJ6srracqXaBta8y6rDzdiMmUSt5SvIryxtj9Ugh+lyVD/1G07JLdKd40gFoutWAmsjv6jeVNbBfEoI8m/oYgo5PgU+Z/EwO0JFkDkUUwikDbENo2Sw2ulmewFjbsjbgcmV0htdnImWDTttyMvd+O3CXn3iKpDsdMO25cqxQMGS/4Wuf0fOd+FMDanzec/2Q/AsVhIbZmfqhJZQrM8fkpuSc7+gL09nihcVn5Sv0LO9x4WVHoRXDJMwVFOVmzZN0pbpnWHZK0/F0ZcOWRvVT5DHjM9BfGVbyG5EVxWi9PjuyY5SLYRC3Qjne3FVnldnTyBPGc4juTwnPUFhjOaN/FKNrbVl6wO x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN9PR11MB5515.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(8676002)(82960400001)(71200400001)(83380400001)(26005)(2616005)(86362001)(30864003)(186003)(5660300002)(6916009)(508600001)(38070700005)(122000001)(6486002)(2906002)(8936002)(6506007)(53546011)(91956017)(76116006)(66946007)(6512007)(64756008)(66446008)(66556008)(66476007)(316002)(36756003)(38100700002)(99106002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SWNrdlJaQW5yRjNiYVJycGErMERxdExwM0hmZzdVekpPaVZiT0RXMFR6SnU5?= =?utf-8?B?SEVzK05jaW4vaE9kQk5zWksxcHp3bkU2RDVVNEp1UGJKMENDeHdOSmtQU3Ji?= =?utf-8?B?ZVh5dmtzUjNhM084d280LzYrVUJtQk5KSW1tM0pZU05NVGY0dzdkRHdhZDYv?= =?utf-8?B?WStIVVBuci9FdTVaNS9oYW9ENE5NdTBYTUtSbGNuUXpZNm5vaFo4RHRWdzVh?= =?utf-8?B?SGp5Qyt3UVlYYUpMWVE4ek5HVEQwZFFsZytWeEtFOGh0NWZhbEUyeTMza1BQ?= =?utf-8?B?bUlzYTZDaGdYVWRTYjNtYzNLNW4xaTdIemVUUzdXWHZyRjJTWmlGc3piS3NL?= =?utf-8?B?TWdIcGRtajlyTHhSa01ZTVVnRjFXOHkrODlRTGVZcVBRZUlXWXJuTW4wQTgy?= =?utf-8?B?WWZhdkFnYjM4QTF3Nkh1bTd0RjBXVVpNUUtsV3ZGRFJVR21SUFRFWDNtUjNz?= =?utf-8?B?S3JoR1YyNzQrbXk3V1Z5VkZtdlVhcGxBUHNjR2tBQTFPZ3pZc3NncTFWM1FG?= =?utf-8?B?bFcwTGl1cVRab0w0cDdLdDFUMWRlZjhQTWF4UXB3NkxGVFY4dlpqbFJPQ2I2?= =?utf-8?B?N3ZBU3hPUHNBdk9Tam9wc3hxTkxaMkZadlNHNVM1RWFYWGowWXpZQmRzd29W?= =?utf-8?B?MmRBcVgvaTM4ajd3Q2h6dzZtYkIvdXQyalpZY2pac2tWTXJuVW5JOVMxU2JX?= =?utf-8?B?aWduOUlnY2diNkpDSDhxRExmNytkM2JmSys5SWJZaHVreWtDYmV1SVpwdXZi?= =?utf-8?B?VTRQNmw1WUpUT0hFYTJOU3ZkYyswNXk4d25WVHQzZEpLMmd5WkJHM2Rjbjll?= =?utf-8?B?QWFYOFNzTnc0K0xIbDhoRjdIVUhoU2pPdzRXWG1CbHJCclEyWEFmemJyRzVv?= =?utf-8?B?NERXMDl3bzVVQXJOY0lMdFo5ZlJjaWdEdVIwcTQxT1FsUkNScWJhVHJ6OEVD?= =?utf-8?B?UHRyMUVzQUNKL0tzR3BDMDNHbStjNll1ZmcvK1F6bDk0cDRtMmsyQWlyeDkr?= =?utf-8?B?T1BkTTRyNmp5SHhIR0hjT3gzcmJLemxVcE95bTQvZkgzVmxwQ1VZTG40VzIz?= =?utf-8?B?VnBEL2VQN2FzRTVRcjgyVGpMUFVSNGdYV1ZDY0xRUE9RaHJudmhrQW9ueFhw?= =?utf-8?B?OURLSzRUS1FrWENMVHhYeGNPYmtoTTE0bm1XWno0VW0xbGsvYWlQaVpWU0xG?= =?utf-8?B?SFBadnQvZDhCcTROcThKQVQ4czhxVDUxZ1NkUEh2blpReEVkeGRhbmlZRGFz?= =?utf-8?B?c3ozalZBOFFDZ3FOZmJyalpYaEN1cytHZU9TTkNRdzZFcnpnZlFxZlo1MWFS?= =?utf-8?B?dE43S1FXcGxOanRjVjVzQWNaa1M0TFpTbm03RjhZSTM1azRUVmhKVkw1b2Nm?= =?utf-8?B?dGJIOWlybU1WUFZES1l0N2Q2UVpqWW9yQVpMT2orcmFOVXY4UVlMV3JyOGZS?= =?utf-8?B?M213YXpKZVpmbmdXU2k1elluVGViZkk2cHVLeW9LcjAvaEJxUUdSeXFMaGds?= =?utf-8?B?Z1hFZk4zY3FienFtRHF2L0h6WW9qRUJpQmFZWWZ4QkhmRkJ6djhJY0lqS3Ey?= =?utf-8?B?S2ZXK1VreTJOV1NWZnJkM0xHaTFFejVFQUs5QTdQcGVod21WZTd3ZE54b1kz?= =?utf-8?B?c2MxYVdoN1g2SkJqQnc5NkFJd3NlZ0tIN0RpYWEwZGxPSFhYSXpGTG9MK3B3?= =?utf-8?B?Sk1lcGZiV3F0a213UGtDdml3WmpRWWFpNnhPOTBSNWI3RmdzbldwYS9UWUR3?= =?utf-8?B?Q1R1SDkyMHJRN0hoVmtqM3E5eFB0bm5aSWQvYUtPUGc4eDVYR1RjOEhnaGVJ?= =?utf-8?B?ZDZrV3RhK3NaS29oZ1ZNRTBXd0tnWTRIWnBFdHZEQ0tHTDJYQkk5Qi9GdC9o?= =?utf-8?B?aEhtTGNWc09RZWZpVy90VUtheDZhakhQcXprTk1uREhGa2srOFdkRFRtVlNJ?= =?utf-8?B?MmlCWWVDdlJsL2h2RGpFRGs5RWs1cFBhTi9EVVRCc3VJN1p2Y05QVEp2WVNC?= =?utf-8?B?bXo0eGQxM3ZhZ0FWK2Q2ZVhMSW83N283YVIxMnFhci9aeHBlN1ZNUlVZM3R6?= =?utf-8?B?NStzMEtDQk10UlF2N0NOVFRYL3VLYVV1ZTBBaks0eEpUWUxVVVBubzB5emZo?= =?utf-8?B?blBEWGpYTXBiU0U2UjNVcVB2TWpCUEN3dDdjSVpHcEVIcWpoKzdqWms1NWkz?= =?utf-8?Q?xl8f5b3c6F4dyhxCOwtJi+E=3D?= Content-ID: <22BE5B98EC4E6F43ACED87B81150F48F@namprd11.prod.outlook.com> MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5515.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c123549a-a62d-4c79-40bf-08d9d40514b0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2022 06:47:33.6018 (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: ui09h85tZNLTfaLtAtjYp8KJiLRwLkoQhUEiWCOnJTCNdqKPyOrt5qZ749UXMa1qFkZ31w5JOSb2ADyJTKUVdQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1411 X-OriginatorOrg: intel.com Subject: Re: [FFmpeg-devel] [PATCH v4 1/1] avutils/hwcontext: When deriving a hwdevice, search for existing device in both directions 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 Mon, 2022-01-10 at 01:40 +0000, Soft Works wrote: > > -----Original Message----- > > From: ffmpeg-devel On Behalf Of Mark > > Thompson > > Sent: Monday, January 10, 2022 1:57 AM > > To: ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] [PATCH v4 1/1] avutils/hwcontext: When deriving > > a > > hwdevice, search for existing device in both directions > > > > On 09/01/2022 23:36, Soft Works wrote:>> -----Original Message----- > > > > From: ffmpeg-devel On Behalf Of Mark > > > > Thompson > > > > Sent: Monday, January 10, 2022 12:13 AM > > > > To: ffmpeg-devel@ffmpeg.org > > > > Subject: Re: [FFmpeg-devel] [PATCH v4 1/1] avutils/hwcontext: When > > > > deriving a > > > > hwdevice, search for existing device in both directions > > > > > > > > On 09/01/2022 21:15, Soft Works wrote: > > > > > > -----Original Message----- > > > > > > From: ffmpeg-devel On Behalf Of > > > > > > Mark > > > > > > Thompson > > > > > > Sent: Sunday, January 9, 2022 7:39 PM > > > > > > To: ffmpeg-devel@ffmpeg.org > > > > > > Subject: Re: [FFmpeg-devel] [PATCH v4 1/1] avutils/hwcontext: When > > > > > > > > deriving a > > > > > > hwdevice, search for existing device in both directions > > > > > > > > > > > > On 05/01/2022 03:38, Xiang, Haihao wrote: > > > > > > > ... this patch really fixed some issues for me and others. > > > > > > > > > > > > Can you explain this in more detail? > > > > > > > > > > > > I'd like to understand whether the issues you refer to are something > > > > which > > > > > > would be fixed by the ffmpeg utility allowing selection of devices > > > > > > for > > > > > > libavfilter, or whether they are something unrelated. > > > > > > > > > > > > (For library users the currently-supported way of getting the same > > > > device > > > > > > again is to keep a reference to the device and reuse it. If there > > > > > > is > > > > some > > > > > > case where you can't do that then it would be useful to hear about > > > > > > it.) > > > > > > > > > > Hi Mark, > > > > > > > > > > they have 3 workaround patches on their staging repo, but I'll let > > > > > Haihao > > > > > answer in detail. > > > > > > > > > > I have another question. I've been searching high and low, yet I can't > > > > > find the message. Do you remember that patch discussion from (quite a > > > > > few) months ago, where it was about another QSV change (something > > > > > about > > > > > device creation from the command line, IIRC). There was a command line > > > > > example with QSV and you correctly remarked something like: > > > > > "Do you even know that just for this command line, there are 5 device > > > > > creations happening in the background, implicit and explicit, and in > > > > > one case (or 2), it's not even creating the specified device but > > > > > a session for the default device instead" > > > > > (just roughly from memory) > > > > > > > > > > Do you remember - or was it Philip? > > > > > > > > > > > > > > > > > Anyway, this is something that the patch will improve. There has been > > > > > one > > > > > other commit since that time regarding explicit device creation from > > > > > Haihao (iirc), which already reduced the device creation and fixed the > > > > > incorrect default session creation. > > > > > > > > Yes, the special ffmpeg utility code to work around the lack of > > > > AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX in the libmfx decoders caused > > > > confusion by working differently to everything else - implementing that > > > > and > > > > getting rid of the workarounds was definitely a good thing. > > > > > > > > > My patch tackles this from another side: at that time, you (or Philip) > > > > > explained that the secondary context that QSV requires (VAAPI, D3Dx) > > > > > and that is initially created when setting up the QSV device, does not > > > > > even get used when subsequently deriving to a context of that kind. > > > > > Instead, a new device is being created in this case. > > > > > > > > > > That's another scenario which is fixed by this patch. > > > > > > > > It does sound like you just always want a libmfx device to be derived > > > > from > > > > the thing which is really there sitting underneath it. > > > > > > "That's another scenario which is fixed by this patch" > > > > > > Things stop working as expected as soon as you are working with 3 or more > > > derived hw devices and neither hwmap nor hwmap-revere can get you to the > > > context you want. > > > > And your situation is sufficiently complex that specifying devices > > explicitly > > is probably what you want, rather that trying to trick some implicit route > > into returning the answer you already know. > > > > > > If you are a library user then you get the original hw context by > > > > reusing > > > > the > > > > reference to it that you made when you created it. This includes > > > > libavfilter > > > > users, who can provide a hw device to each hwmap separately. > > > > > > > > If you are an ffmpeg utility user then I agree there isn't currently a > > > > way > > > > to > > > > do this for filter graphs, hence the solution of providing an a way in > > > > the > > > > ffmpeg utility to set hw devices per-filter. > > > > > > just setting the context on a filter doesn't make any sense, because you > > > > need > > > the mapping. It only makes sense for the hwmap and hwupload filters. > > > > Yes? The filters you need to give it to are the hwmap and hwupload filters, > > the others indeed don't matter (though they are blindly set at the moment > > because there is no way to know they don't need it). > > > > > > > Anyway I'm wondering whether it can even be logically valid to derive > > > > > from one device to another and then to another instance of the > > > > > previous > > > > > device type. > > > > > From my understanding, "deriving" or "hw mapping" from one device to > > > > > another means to establish a different way or accessor to a common > > > > > resource/data, which means that you can access the data in one or the > > > > > other way. > > > > > > > > > > Now let's assume a forward device-derivation chain like this: > > > > > > > > > > D3D_1 >> OpenCL_1 >> D3D_2 > > > > > > > > You can't do this because device derivation is unidirectional (and > > > > acyclic) - > > > > you can only derive an OpenCL device from D3D (9 or 11), not the other > > > > way > > > > around. > > > > > > > > Similarly, you can only map frames from D3D to OpenCL. That's why the > > > > hwmap > > > > reverse option exists, because of cases where you actually want the > > > > other > > > > direction which doesn't really exist. > > > > > > Yes, all true, but my point is something else: you can't have several > > > > context > > > of the same type in a derivation chain. > > > > That's a consequence of unidirectionality + acyclity, yes. > > > > > And that's exactly what this patch addresses: it makes sure that you'll > > > get > > > an existing context instead of ffmpeg trying to derive to a new hw device > > > which doesn't work anyway. > > > > I'm still only seeing one case where this bizarre operation is wanted: the > > ffmpeg utility user trying to get devices into the right place in their > > filter graphs, who I still think would be better served by being able to set > > the right device directly on hwmap rather than implicitly through searching > > derivation chains. > > > > > > > We have D3D surfaces, then we share them with OpenCL. Both *_1 > > > > > contexts provide access to the same data. > > > > > Then we derive again "forward only" and we get a new D3D_2 > > > > > context. It is derived from OpenCL_1, so it must provide > > > > > access to the same data as OpenCL_1 AND D3D_1. > > > > > > > > > > Now we have two different D3D contexts which are supposed to > > > > > provide access to the same data! > > > > > > > > > > > > > > > 1. This doesn't even work technically > > > > > - neither from D3D (iirc) > > > > > - nor from ffmpeg (not cleanly) > > > > > > > > > > 2. This doesn't make sense at all. There should always be > > > > > only a single device context of a device type for the same > > > > > resource > > > > > > > > > > 3. Why would somebody even want this - what kind of use case? > > > > > > > > The multiple derivation case is for when a single device doesn't work. > > > > Typically that involves multiple separate components which don't want to > > > > interact with the others, for example: > > > > > > > > * When something thread-unsafe might happen, so different threads need > > > > separate instances to work with. > > > > > > Derivation means accessing shared resources (computing and memory), and > > > you can't solve a concurrency problem by having two devices accessing > > > the same resources - this makes it even worse (assuming a device would > > > even allow this). > > > > Device derivation means making a compatible context of a different type on > > the same physical device. > > > > Now that's probably intended because you are going to want to share some > > particular resources, but exactly what can be shared and what is possible is > > dependent on the setup. > > > > Similarly, any rules for concurrency are dependent on the setup - maybe you > > can't do two specific things simultaneously in the same device context and > > need two separate ones to solve it, but they still both want to share in > > some > > way with the different device context they were derived from. > > > > > > * When global options have to be set on a device, so a component which > > > > does > > > > that needs its own instance to avoid interfering with anyone else. > > > > > > This is NOT derivation. This case is not affected. > > > > Suppose I have some DRM frames which come from somewhere (some hardware > > decoder, say - doesn't matter). > > > > I want to do Vulkan things with some of the frames, so I call > > av_hwdevice_ctx_create_derived_opts() to get a compatible Vulkan context. > > Then I can map and do Vulkan things, yay! > > > > Later on, I want to do some independent Vulkan thing with my DRM frames. I > > do the same operation again with different options (because my new thing > > wants some new extensions, say). This returns a new Vulkan context and I > > can > > work with it completely independently, yay! > > You are describing the creation of a Vulkan context with other parameters > with which you can work independently. > > That's not my understanding of deriving a context. I don't the implementation > in case of Vulkan, but in case of the others, deriving is about sharing > resources. And when you share resources, you can't "work with it > independently", > so what you're talking about is not a scenario of deriving a context. > > > To wrap things up a bit: > > - you want an approach which requires even more complicated filter > command lines. > I have understood that. It is a possible addition for filter command lines > and I would even welcome somebody who would implement precise hw context > selection for hwdownload and also for hwmapn for (rare) cases where this > might be needed. (that somebody won't be me, though) > > - but this is not what this patchset is about. it is about having things > working nicely and automatically in a way as one would expect it instead > of failing. this patchset only touches and changes behavior in those cases > that are currently failing anyway > > - Or can you name any realistic use case that this patchset would break? > (if yes, let's please go through a specific example with pseudo code) > > > Maybe Haihao's reply will be more convincing. > It might also be interesting what the Vulkan guys are thinking about it > (as there has been some feedback from that side earlier). Hi Mark, We want to provide a more user friendly command-line to share gfx memory between QSV, VAAPI and other HW methods. E.g. VAAPI provides sharpness_vaapi but QSV doesn't provide a corresponding filter, we want to use sharpness_vaapi filter on the output from QSV decoders. Currently the first command-line below may work, however the second command line below can't work because QSV device is not derived from a VAAPI device explicitly, so ffmpeg fails to derive VAAPI device from QSV device (it may derive VAAPI device from QSV device in the first case) $ ffmpeg -init_hw_device vaapi=intel -init_hw_device qsv=qsv@intel -hwaccel qsv -c:v h264_qsv -i input.mp4 -vf hwmap=derive_device=vaapi,sharpness_vaapi -f null - $ ffmpeg -hwaccel qsv -c:v h264_qsv -i input.mp4 -vf hwmap=derive_device=vaapi,sharpness_vaapi -f null - After applying Softworks' patch, the above two command-lines may work well. In addition, we may use other HW methods on QSV output without copy for gfx memory, e.g. $ ffmpeg -hwaccel qsv -c:v h264_qsv -i input.mp4 -vf "hwmap=derive_device=vaapi,format=vaapi,hwmap=derive_device=vulkan,scale_vulkan= w=1920:h=1080" -f null - Thanks Haihao _______________________________________________ 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".