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 3FAD740E7C for ; Fri, 11 Mar 2022 14:00:55 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id DAA2168B1C2; Fri, 11 Mar 2022 16:00:53 +0200 (EET) Received: from mail-yw1-f176.google.com (mail-yw1-f176.google.com [209.85.128.176]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 1600C68A774 for ; Fri, 11 Mar 2022 16:00:48 +0200 (EET) Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-2dc348dab52so94030867b3.6 for ; Fri, 11 Mar 2022 06:00:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Lxh1r6JwWdfJGSKeqfwlhrV647Li5WI/j2vnEF3LDno=; b=NJk/l7CST4XNg4XJiOGlFpDyKZb+vY7HaaYvCxH1bDfqn6Lv77HX8VyYG0M0inZEid YvuUWbtQ419B3tSggtilc8IvMrbF2iAX+nHcndTJzrWWcvbn0Zm8QTW/MdsNVI1j8TvI ars/+D4CEvCdiEf7ODl6e4i7Y8ojoXUHH1NFXABZPJdVVmfsKiGPPn9IlAtfrfTCP9CC 780sHBx/L8Q2C040oOzLL8bqYqcZfN4fl/Rev8RAVLnSGNMdzvl++Nn/QUL3agySE0SK uKKyZybF/bfk6tAsEt58vmuOwU3eX/s0+BaeApWQBlJc2sKA+7NpcdZbFfgBGuaVlswD hCbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Lxh1r6JwWdfJGSKeqfwlhrV647Li5WI/j2vnEF3LDno=; b=03GGDbvNJ3D3atsrWtxdYyuzupqWpx4SGB5LrtwK2SBTFzNdsCWf6feGUfUn3AOmxu 3UdzzRzfbEbsnLd/a+VB2QJVplA3pMIP7uRjN/hnUoUC3nYJqSmx7+esrAIAPApRj+Nr MNdc8+/oir14Q/S4dXBBcIjmRU7wHoApWnGkQKsDJaZKnP/2KEiHKCCS8HkswR59yZqW 78nLXqPM+9436Kvu2eWO1KHBKtAsxUqqHboa+tUaNB20GqpVFZ0fO3FzbuhxbEV+ROPa gy+etYZDnpwjg92Py/paM0lHHBA09Q8hn8oyBV6GFm+nYJzYkcH3icW3ZqixzC/zwjot CLqA== X-Gm-Message-State: AOAM531N1FGxHkk8xsDST0yZblHIrZv+SYM+GLhBP3x1UOM7jy4Rm8Rv b1Ptz2bppqJJTvIpfzvu5I7cKCtfLUJELOZyAUWS3IuJsa4= X-Google-Smtp-Source: ABdhPJxAW+gh3DcgqFzXy0g4Pye2d0zuu/TS5h9nr5vBbsBKRVMBjVKxchJt8S02YVV8gDzmOQ4YthmaxeEopTThBaA= X-Received: by 2002:a81:851:0:b0:2dc:e987:7acb with SMTP id 78-20020a810851000000b002dce9877acbmr8253300ywi.439.1647007246436; Fri, 11 Mar 2022 06:00:46 -0800 (PST) MIME-Version: 1.0 References: <20220311081630.21927-1-haihao.xiang@intel.com> <20220311081630.21927-10-haihao.xiang@intel.com> <1202f7ddc68d529bd517aeeb4190bacd9783db79.camel@intel.com> In-Reply-To: <1202f7ddc68d529bd517aeeb4190bacd9783db79.camel@intel.com> From: Hendrik Leppkes Date: Fri, 11 Mar 2022 15:00:33 +0100 Message-ID: To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH v7 09/10] qsv: use a new method to create mfx session when using oneVPL 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 Fri, Mar 11, 2022 at 2:43 PM Xiang, Haihao wrote: > > On Fri, 2022-03-11 at 09:35 +0100, Hendrik Leppkes wrote: > > On Fri, Mar 11, 2022 at 9:18 AM Xiang, Haihao > > wrote: > > > diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c > > > index 8ab96bad25..e0e820f164 100644 > > > --- a/libavutil/hwcontext_d3d11va.c > > > +++ b/libavutil/hwcontext_d3d11va.c > > > @@ -525,6 +525,13 @@ static void d3d11va_device_uninit(AVHWDeviceContext > > > *hwdev) > > > } > > > } > > > > > > +static void d3d11va_device_free(AVHWDeviceContext *ctx) > > > +{ > > > + AVD3D11VADeviceContext *hwctx = ctx->hwctx; > > > + > > > + av_free(hwctx->device_name); > > > +} > > > + > > > static int d3d11va_device_create(AVHWDeviceContext *ctx, const char > > > *device, > > > AVDictionary *opts, int flags) > > > { > > > @@ -537,6 +544,8 @@ static int d3d11va_device_create(AVHWDeviceContext *ctx, > > > const char *device, > > > int is_debug = !!av_dict_get(opts, "debug", NULL, 0); > > > int ret; > > > > > > + ctx->free = d3d11va_device_free; > > > + > > > // (On UWP we can't check this.) > > > #if !HAVE_UWP > > > if (!LoadLibrary("d3d11_1sdklayers.dll")) > > > @@ -561,6 +570,10 @@ static int d3d11va_device_create(AVHWDeviceContext > > > *ctx, const char *device, > > > if (FAILED(IDXGIFactory2_EnumAdapters(pDXGIFactory, adapter, > > > &pAdapter))) > > > pAdapter = NULL; > > > IDXGIFactory2_Release(pDXGIFactory); > > > + > > > + device_hwctx->device_name = av_strdup(device); > > > + if (!device_hwctx->device_name) > > > + return AVERROR(ENOMEM); > > > } > > > } > > > > > > diff --git a/libavutil/hwcontext_d3d11va.h b/libavutil/hwcontext_d3d11va.h > > > index 77d2d72f1b..41a315b9e6 100644 > > > --- a/libavutil/hwcontext_d3d11va.h > > > +++ b/libavutil/hwcontext_d3d11va.h > > > @@ -94,6 +94,11 @@ typedef struct AVD3D11VADeviceContext { > > > void (*lock)(void *lock_ctx); > > > void (*unlock)(void *lock_ctx); > > > void *lock_ctx; > > > + > > > + /** > > > + * The string for the used adapter > > > + */ > > > + char *device_name; > > > } AVD3D11VADeviceContext; > > > > > > /** > > > diff --git a/libavutil/hwcontext_dxva2.c b/libavutil/hwcontext_dxva2.c > > > index 53d00fa815..6967357093 100644 > > > --- a/libavutil/hwcontext_dxva2.c > > > +++ b/libavutil/hwcontext_dxva2.c > > > @@ -431,6 +431,7 @@ static void dxva2_device_free(AVHWDeviceContext *ctx) > > > dlclose(priv->dxva2lib); > > > > > > av_freep(&ctx->user_opaque); > > > + av_free(hwctx->device_name); > > > } > > > > > > static int dxva2_device_create9(AVHWDeviceContext *ctx, UINT adapter) > > > @@ -571,6 +572,13 @@ static int dxva2_device_create(AVHWDeviceContext *ctx, > > > const char *device, > > > return AVERROR_UNKNOWN; > > > } > > > > > > + if (device) { > > > + hwctx->device_name = av_strdup(device); > > > + > > > + if (!hwctx->device_name) > > > + return AVERROR(ENOMEM); > > > + } > > > + > > > return 0; > > > } > > > > > > diff --git a/libavutil/hwcontext_dxva2.h b/libavutil/hwcontext_dxva2.h > > > index e1b79bc0de..253ddbed51 100644 > > > --- a/libavutil/hwcontext_dxva2.h > > > +++ b/libavutil/hwcontext_dxva2.h > > > @@ -38,6 +38,10 @@ > > > */ > > > typedef struct AVDXVA2DeviceContext { > > > IDirect3DDeviceManager9 *devmgr; > > > + /** > > > + * The string for the used adapter > > > + */ > > > + char *device_name; > > > } AVDXVA2DeviceContext; > > > > > > /** > > > > Why are these device names required? I would think deriving a child > > device would use the actual device, eg. ID3D11Device or > > IDirect3DDeviceManager9 (and whatever for VAAPI), and not some string > > (that may or may not even be set). > > It feels quite a bit icky to store these in the context just for qsv > > to do... what with? > > Yes, it is a little ugly here. MediaSDK or oneVPL application creates mfx > session and the device (dxva2, d3d11va or vaapi), then pass this device to the > SDK through MFXVideoCORE_SetHandle(). implementation is introduced in oneVPL ( > https://spec.oneapi.io/versions/latest/elements/oneVPL/source/API_ref/VPL_disp_api_struct.html#structmfx_impl_description > ) and user must select an available implementation before the creation of mfx > session, however the device handle is unknown in the SDK when selecting an > available implementation, the SDK provides a method to select implementation via > the given adapter (on Windows) or DRI device node (on Linux). The default > implementation will be selected if child device name is unknown. > First of all, whoever made that API should get a stern message. Expecting to properly interoperate with the dominant platform APIs should be a primary goal, and it sounds like it was somehow shoehorned in after the fact. For D3D11 for example, you can get the IDXGIAdapter a device was created from, isn't there enough information in there to pass-on without storing a string field? IDXGIAdapter::GetDesc has tons of identification information to identify the device in use. D3D9 probably has something similar, haven't checked right now. - Hendrik _______________________________________________ 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".