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 9DAFC40AC7 for ; Tue, 28 Dec 2021 01:18:12 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 77CF468B0C3; Tue, 28 Dec 2021 03:18:09 +0200 (EET) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10olkn2029.outbound.protection.outlook.com [40.92.41.29]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 78BB368AEEA for ; Tue, 28 Dec 2021 03:18:03 +0200 (EET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Iq2/EZQivXVT6x6yUgGbRQmpXYfI00Eefqb3UwhCYwINPSGGqjjqZF2NE2vGdUIHIxVz7704m/9PahJdnhpVfrPUo0HzIhJJU7xGd3yHUfVHltlfBkLQXSnifQUlAf3GlXKptmm+R6wB/lSF5za4GMMa0FRR3+nO34Fl31M0nD8ILT6Q+xTNnhDU4TzayP60gMwTD3pnIvoS0Uc6XeD8Ee/VuqZthxdwrYQW1lN1Pvz03PvQa85Rgm//6TIQsGL3hQvQPihCcHGPIQFWZRp4USVFTTPZoEQOMAp0q4jaZXNTJs/eap9EV+LH5WTDNHf9MnUD0cDN8YtQbvE2MfsuNw== 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=VeXV8VRHNeLzY78+NirfMtRTyUaSxgaqzNf6oogMR80=; b=PhvoGcX9nw9ymQ/QIPC8Vt1FdxvJFC3c8nRLCk2gl6mLvCr50jwlvx+WG+fYkfPfxJf7rhKdhrrooYwCGWC7hYU+41XqSj1Pg8YXl75BtmbUEeHkFlRp3l7PXgDl6CMj3p0+l6HRmOTRbS0bvdfiKy8DUF9HJ0sPV9cdSFcD5zrFOwdic+f20L8Uv0T+jtpMX/1Ea7kZNZsTqtmWoBL00J8QzMvgU47I1TUpSNTW28q3VY0hNpVy8+4d82Z2T9FH45P50C0pqfhG+Cv6Ywpyd8rQWMsgM94MMeA+FKZuSsCBnAIB0JaZpvFROxJc6YHuV16QyAEfKXpbwsLsxAl8Sw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VeXV8VRHNeLzY78+NirfMtRTyUaSxgaqzNf6oogMR80=; b=ks0lk9hPXbHIeGdDbDXvfLrvvswwxH/bBZm01Nra5PbjXYzJv48brfwofORoZobfXYSkykdvoteq5Eqo2QBHbtw7RyL/vPAJnlbtbEezhUJMSO8MafhATB1h9cW1j6CxiPq06zqc+S/Ryo5wa6TRSXB2WyhzQlvyIbjTqydL96q0d2f8TOIxzxOwA6eB+JL3tKESIgLNwtWzgv6s78h9REJu6XOOXDT9goO0LWQFkZCIcjaLTyL3kIiLsSqOmscTd5AKB8h9QHbzUQi4/bpQL0ufBR5MLXTYGEhk2Z3pE6w9I0g2SWm50jRoRbP+8Qr8rIPUGKo+0Xk6XECDIlhpAA== Received: from DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM (2603:10b6:8:b::20) by DM8P223MB0128.NAMP223.PROD.OUTLOOK.COM (2603:10b6:8:b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4823.19; Tue, 28 Dec 2021 01:17:59 +0000 Received: from DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM ([fe80::9c8d:fc63:9488:9775]) by DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM ([fe80::9c8d:fc63:9488:9775%7]) with mapi id 15.20.4823.023; Tue, 28 Dec 2021 01:17:59 +0000 From: Soft Works To: FFmpeg development discussions and patches Thread-Topic: [FFmpeg-devel] [PATCH 3/3] libavutil/hwcontext_opencl: fix a bug for mapping qsv frame to opencl Thread-Index: AQHX2sLbRTyIEmFJc0+hIglvJzmE7KxG7+iAgAAOPbCAAEQcgIAAFGUg Date: Tue, 28 Dec 2021 01:17:59 +0000 Message-ID: References: <20211116081623.3081766-1-wenbin.chen@intel.com> <20211116081623.3081766-3-wenbin.chen@intel.com> <92735cd0-179b-cbf6-b191-e440be779b66@jkqxz.net> <96dc30bc-2ff0-009b-713c-b41c248d6b6b@jkqxz.net> In-Reply-To: <96dc30bc-2ff0-009b-713c-b41c248d6b6b@jkqxz.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tmn: [AaElVNDUmVVj7bJ/2FUvMasodBt1xXdA] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f1220648-de04-4e1c-c78f-08d9c99fe340 x-ms-traffictypediagnostic: DM8P223MB0128:EE_ x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xQXHkGOruCndprLXR2Q6jugYr8jLHNxYut9vMjRdXc9H7DKEPPRaH9JvcmFzZR8kLnQcN7TsEdQ9p9hKB/1wf7bpatAt6AUNeSneY2C6vqxZyOH5yEVtGv4TJx3TxwjuMaAI2B/lL7VGFqYXODqTIII7msrLhKr2I/8AQi4IQ3RXcDQr0vK3CQXwbyqBd5salsdTIKJVUlppVEcPfU2jq3MnwUYKU1yQTx7/HawFHPDWyvEWP3I6MiX4rZ85iVMUq/Ehck75N7ALRJWelYikwc5isEF6SbLm1y62+/yczpewCxeqeJkFCdsEsa4g2ZrbNWUs5L8cJcwh5cQH1Jq7mq7SgH9h/YzUN5j/6fTI3RrGz+a4PKK5hbhKZkliW2TmU9tUqe+oBQ8qqYZhjCXH0uLGn5GEoLedEXDsAs/bLV7GI7fMg7bdI/j0Oti0htTR/iDmtYcplkRZ4SeUa7F/kWTaPRtl8DQa+LwyybiCaBx3sq7Eu4uBl7JtjKRvDgLmRcrl2ZIvo++B8Lb5rix/j32kys6I0wae/O3xA0fjjxcKnAcXtHqsiR+xG5jdm8JlJtYUA3GDA888t9iuUlcebw== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: EvlrHc8jwJCwvUslrMCxCccG6h3+FAjdEzbwxPpXk4eDtBF4J3eK2AV96SjIGF/QgdW8E/1Q0R/vmLgi52Nqw0u/JOBWs9wXAjpyYkaTuyz4A0mgdaPM2seK6mI5Aigs2yAgfqrsj9r1tw9q6LKiofgZHAtDkIwa86w/fJQRSOjGdeSM+wyqOLJLZjJB/E55FZelBI9fKpAeweB9IrnBqXq4673c4TZIVDwM3j0Dd8SFGvvfQz57Y1c/FCYiqVLk5Iy2EQuo5ev8oRQzfHr9acOm0NZOebuY6BYTef97qrbIQd8/+mglecjvQAKMViH1tlyO+sa6ulF8Jouy5Ro+H7g4pzJfRomZco3pe4aotzufAF6AfHzB+luQ6WL++y49hfDFyp6MIhB6VredIWHzMjk7YKdLxv0b1DEYufyWT8/NHHhVq8Hgc7qbLSj+tYQl3EZf/WKkgEboorn1Pyb/VUNkCWYQ/1gPDkIYecJ9RmOZnP2PpRbjNPx5Mu6Jt2fOABnr84k2jkbeVoBBETCUjMHrGhSFmEc+INr+b0+GAnPKJv6poxkC9sI/p9QW0MDhmkXSO3I9KZWMbb/nILYc0peUt26FMUvQWR4iSv3VCbFtxHGrTdc1QBgxsENrFDMksTiRO+9nY9n169IjnnXc1YCYiObEKCNE8VXidxu5FQInJH11z2Nm6FhASWae4yUIzDehXs/rjtlvsupf8jERG+ct/Sg4GRBA16Yx5Fiurfia0nGSfeY5ArBtgb+/UpSz2ZJYphfZdtqr1HBgtrhaM/h9gnzvC4ryiJpskGUP3gIIoZ73zdYYv84hL0QA4j2do6hfjjLnz1fVZyMAuM9oRTe/yZM6SQgq/93K8Kjzdlnp5PCKuJ5M0zOEWiJyBv6Z2IbDSJEDC2YPwdtx/XUtFPnY8Mi6bvN82HJRHVQroH/WbYjIFV9rwNGFex68KPY1 MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-1ff67.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: f1220648-de04-4e1c-c78f-08d9c99fe340 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Dec 2021 01:17:59.8306 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8P223MB0128 Subject: Re: [FFmpeg-devel] [PATCH 3/3] libavutil/hwcontext_opencl: fix a bug for mapping qsv frame to opencl 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: > -----Original Message----- > From: ffmpeg-devel On Behalf Of Mark > Thompson > Sent: Tuesday, December 28, 2021 12:46 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH 3/3] libavutil/hwcontext_opencl: fix a bug > for mapping qsv frame to opencl > > On 27/12/2021 20:31, Soft Works wrote:>> -----Original Message----- > >> From: ffmpeg-devel On Behalf Of Mark > >> Thompson > >> Sent: Monday, December 27, 2021 7:51 PM > >> To: ffmpeg-devel@ffmpeg.org > >> Subject: Re: [FFmpeg-devel] [PATCH 3/3] libavutil/hwcontext_opencl: fix a > bug > >> for mapping qsv frame to opencl > >> > >> On 16/11/2021 08:16, Wenbin Chen wrote: > >>> From: nyanmisaka > >>> > >>> mfxHDLPair was added to qsv, so modify qsv->opencl map function as well. > >>> Now the following commandline works: > >>> > >>> ffmpeg -v verbose -init_hw_device vaapi=va:/dev/dri/renderD128 \ > >>> -init_hw_device qsv=qs@va -init_hw_device opencl=ocl@va -filter_hw_device > >> ocl \ > >>> -hwaccel qsv -hwaccel_output_format qsv -hwaccel_device qs -c:v h264_qsv > \ > >>> -i input.264 -vf > "hwmap=derive_device=opencl,format=opencl,avgblur_opencl, > >> \ > >>> hwmap=derive_device=qsv:reverse=1:extra_hw_frames=32,format=qsv" \ > >>> -c:v h264_qsv output.264 > >>> > >>> Signed-off-by: nyanmisaka > >>> Signed-off-by: Wenbin Chen > >>> --- > >>> libavutil/hwcontext_opencl.c | 3 ++- > >>> 1 file changed, 2 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c > >>> index 26a3a24593..4b6e74ff6f 100644 > >>> --- a/libavutil/hwcontext_opencl.c > >>> +++ b/libavutil/hwcontext_opencl.c > >>> @@ -2249,7 +2249,8 @@ static int opencl_map_from_qsv(AVHWFramesContext > >> *dst_fc, AVFrame *dst, > >>> #if CONFIG_LIBMFX > >>> if (src->format == AV_PIX_FMT_QSV) { > >>> mfxFrameSurface1 *mfx_surface = (mfxFrameSurface1*)src- > >data[3]; > >>> - va_surface = *(VASurfaceID*)mfx_surface->Data.MemId; > >>> + mfxHDLPair *pair = (mfxHDLPair*)mfx_surface->Data.MemId; > >>> + va_surface = *(VASurfaceID*)pair->first; > >>> } else > >>> #endif > >>> if (src->format == AV_PIX_FMT_VAAPI) { > >> > >> Since these frames can be user-supplied, this implies that the user-facing > >> API/ABI for AV_PIX_FMT_QSV has changed. > >> > >> It looks like this was broken by using HDLPairs when D3D11 was introduced, > >> which silently changed the existing API for DXVA2 and VAAPI as well. > >> > >> Could someone related to that please document it properly (clearly not all > >> possible valid mfxFrameSurface1s are allowed), and note in APIchanges when > >> the API change happened? > > > > Hi Mark, > > > > QSV contexts always need to be backed by a child context, which can be > DXVA2, > > D3D11VA or VAAPI. You can create a QSV context either by deriving from one > of > > those contexts or when create a new QSV context, it automatically creates > an > > appropriate child context - either implicitly (auto mode) or explicitly, > like > > the ffmpeg implementation does in most cases. > > ... or by using the one the user supplies when they create it. > > > When working with "user-supplied" frames on Linux, you need to create a > VAAPI > > context with those frames and derive a QSV context from that context. > > > > There is no way to create or supply QSV frames directly. > > ??? The ability for the user to set up their own version of these things is > literally the whole point of the split alloc/init API. > > > // Some user stuff involving libmfx - has a D3D or VAAPI backing, but this > code doesn't need to care about it. > > // It has a session and creates some surfaces to use with MemId filled > compatible with ffmpeg. > user_session = ...; > user_surfaces = ...; > > // No ffmpeg involved before this, now we want to pass these surfaces we've > got into ffmpeg. > > // Create a device context using the existing session. > > mfx_ctx = av_hwdevice_ctx_alloc(MFX); > > dc = mfx_ctx->data; > mfx_dc = dc->hwctx; > mfx_dc->session = user_session; > > av_hwdevice_ctx_init(mfx_ctx); > > // Create a frames context out of the surfaces we've got. > > mfx_frames = av_hwframes_ctx_alloc(mfx_ctx); > > fc = mfx_frames->data; > fc.pool = user_surfaces.allocator; > fc.width = user_surfaces.width; > // etc. > > mfx_fc = fc->hwctx; > mfx_fc.surfaces = user_surfaces.array; > mfx_fc.nb_surfaces = user_surfaces.count; > mfx_fc.frame_type = user_surfaces.memtype; > > av_hwframe_ctx_init(frames); > > // Do stuff with frames. I wouldn't consider an mfxSession as an entity that could or should be shared between implementations. IMO, this is not a valid use case. A consumer of the mfx API needs to make certain choices regarding the usage of the API, one of which is the way how frames are allocated and managed. This is not something that is meant to be shared between implementations. Even inside ffmpeg, we don't use a single mfx session. We use separate sessions for decoding, encoding and filtering that are joined together via MFXJoinSession. When an (ffmpeg-)API consumer is creating its own MFX session and its own frame allocator implementation, it shouldn't be and allowed scenario to create an ffmpeg hw context using this session. This shouldn't be considered a public API of ffmpeg because it doesn't make sense to share an mfx session like this. Besides that, is there any ffmpeg documentation indicating that the memId field of mfxFrameSurface1 could be casted to VASurfaceId? Kind regards, softworkz _______________________________________________ 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".