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 91ABA427C8 for ; Sat, 30 Apr 2022 16:14:22 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id BE98168B298; Sat, 30 Apr 2022 19:14:19 +0300 (EEST) Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 3556868B1E4 for ; Sat, 30 Apr 2022 19:14:13 +0300 (EEST) Received: by mail-wr1-f49.google.com with SMTP id x18so14455072wrc.0 for ; Sat, 30 Apr 2022 09:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jkqxz-net.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=ZrSrCuF7KnyWYwrei94IzIarmMPPyRb/6/WeUW/6RCU=; b=G/hPI6noeFQQb+RW1Ge4pGTgR73k21sRVrHgt2CawNOoxjShbus6A3IrAmOF5OrmyQ M/0UEDKhADfUSyRM4T3Nrb1/7+NxpEbPkVKyIrUzPjG7d4AVmXhIM+tjRfhupMH4oiIF NLDTg/oGo0eEbIy/8+u9jfWC4O8kd6KBHOy8MCh5nIpPeZQa60mzGr29Oh5djERPv8u9 oRO7GOISvv+60kK9UD5iroldJLh24o0v6Ix5yvn26RCHRdr+FYPhgSyngofJWWzHF8of CnyUv2lrOnQuAtGDt75QBizBXzPcq6vyUBfgTr1Maw/XLNlMvB5ywJmypHGIv11nmjVu E1tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=ZrSrCuF7KnyWYwrei94IzIarmMPPyRb/6/WeUW/6RCU=; b=TfQyTybLvQa1HqYADfCZ72Epy7hSbkUbbMjFE5/yFkzSEwNml4ybqEnWePeqMZKIln ah+7Po8u7DJKATf6V1tmHmjabvq12/GivYhsazzk6+7/CJGaFNO1PIC8+xSE34YWdnJf AtA6vDGxPuOaT53kRhBxeNtMj06290XoL/0ATKVNKhu6H0Yc7fY4Ea41/a8kYIYv6MHw QxJaP3ZhPb8oUSJfs5pCRv15SxGjHd+a9KLRVGkxj3+XrVdEV6zyKLqBWUUDY5CG3On6 NJt/WWByP68V4Br3K59LtdEHSotrfw+y6F/23GGZlzKVRntdJ0y5bFNarhtiYLef52ZC cjCA== X-Gm-Message-State: AOAM530V7zkMZEKlH8PFPgKe/h83XgF9JApIOB1hI38EeVg8kqGCAteR o+a4WxlmDuigR/iEb7dTBqHFDKogSXJD7xCI X-Google-Smtp-Source: ABdhPJzEflCzkVGzyXVYlgeoMrAEDL3r/eT/mCtmMrhfhb5i7w3xnnjLgnZ8s7ocJ8J0pMwP6TKX9g== X-Received: by 2002:a5d:5749:0:b0:20a:ce36:b29 with SMTP id q9-20020a5d5749000000b0020ace360b29mr3450411wrw.559.1651335252656; Sat, 30 Apr 2022 09:14:12 -0700 (PDT) Received: from [192.168.0.11] (cpc91222-cmbg18-2-0-cust46.5-4.cable.virginm.net. [81.106.30.47]) by smtp.gmail.com with ESMTPSA id q8-20020a1ce908000000b003942a244eeasm2093766wmc.47.2022.04.30.09.14.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 30 Apr 2022 09:14:12 -0700 (PDT) Message-ID: <63eba3b2-afb4-6189-cd36-0ba0c1d45934@jkqxz.net> Date: Sat, 30 Apr 2022 17:14:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20220428092327.16558-1-haihao.xiang@intel.com> <20220428092327.16558-10-haihao.xiang@intel.com> From: Mark Thompson In-Reply-To: <20220428092327.16558-10-haihao.xiang@intel.com> Subject: Re: [FFmpeg-devel] [PATCH v08 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 28/04/2022 10:23, Haihao Xiang wrote: > In oneVPL, MFXLoad() and MFXCreateSession() are required to create a > workable mfx session[1] > > Add config filters for D3D9/D3D11 session (galinart) > > The default device is changed to d3d11va for oneVPL when both d3d11va > and dxva2 are enabled on Microsoft Windows > > This is in preparation for oneVPL support > > [1] https://spec.oneapi.io/versions/latest/elements/oneVPL/source/programming_guide/VPL_prg_session.html#onevpl-dispatcher > > Co-authored-by: galinart > Signed-off-by: galinart > --- > libavcodec/qsv.c | 197 ++++++++++-- > libavcodec/qsv_internal.h | 1 + > libavcodec/qsvdec.c | 10 + > libavcodec/qsvenc.h | 3 + > libavcodec/qsvenc_h264.c | 1 - > libavcodec/qsvenc_hevc.c | 1 - > libavcodec/qsvenc_jpeg.c | 1 - > libavcodec/qsvenc_mpeg2.c | 1 - > libavcodec/qsvenc_vp9.c | 1 - > libavfilter/qsvvpp.c | 113 ++++++- > libavfilter/qsvvpp.h | 5 + > libavfilter/vf_deinterlace_qsv.c | 14 +- > libavfilter/vf_scale_qsv.c | 12 +- > libavutil/hwcontext_d3d11va.c | 7 + > libavutil/hwcontext_qsv.c | 515 ++++++++++++++++++++++++++++--- > libavutil/hwcontext_qsv.h | 1 + > libavutil/hwcontext_vaapi.c | 13 + > libavutil/hwcontext_vaapi.h | 4 + > 18 files changed, 812 insertions(+), 88 deletions(-) > > ... > diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c > index 8ab96bad25..fd5fedbdac 100644 > --- a/libavutil/hwcontext_d3d11va.c > +++ b/libavutil/hwcontext_d3d11va.c > @@ -525,6 +525,11 @@ static void d3d11va_device_uninit(AVHWDeviceContext *hwdev) > } > } > > +static void d3d11va_device_free(AVHWDeviceContext *ctx) > +{ > + AVD3D11VADeviceContext *hwctx = ctx->hwctx; > +} > + > static int d3d11va_device_create(AVHWDeviceContext *ctx, const char *device, > AVDictionary *opts, int flags) > { > @@ -537,6 +542,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")) This change doesn't do anything. > ... > diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c > index c3a98bc4b1..cb714df934 100644 > --- a/libavutil/hwcontext_vaapi.c > +++ b/libavutil/hwcontext_vaapi.c > @@ -1572,6 +1572,7 @@ static void vaapi_device_free(AVHWDeviceContext *ctx) > if (priv->drm_fd >= 0) > close(priv->drm_fd); > > + av_free(hwctx->device_name); > av_freep(&priv); > } > > @@ -1620,6 +1621,7 @@ static int vaapi_device_connect(AVHWDeviceContext *ctx, > static int vaapi_device_create(AVHWDeviceContext *ctx, const char *device, > AVDictionary *opts, int flags) > { > + AVVAAPIDeviceContext *hwctx = ctx->hwctx; > VAAPIDevicePriv *priv; > VADisplay display = NULL; > const AVDictionaryEntry *ent; > @@ -1665,6 +1667,11 @@ static int vaapi_device_create(AVHWDeviceContext *ctx, const char *device, > "DRM device node.\n", device); > break; > } > + > + hwctx->device_name = av_strdup(device); > + > + if (!hwctx->device_name) > + return AVERROR(ENOMEM); > } else { > char path[64]; > int n, max_devices = 8; > @@ -1705,6 +1712,12 @@ static int vaapi_device_create(AVHWDeviceContext *ctx, const char *device, > av_log(ctx, AV_LOG_VERBOSE, "Trying to use " > "DRM render node for device %d.\n", n); > } > + > + hwctx->device_name = av_strdup(path); > + > + if (!hwctx->device_name) > + return AVERROR(ENOMEM); > + > break; > } > if (n >= max_devices) > diff --git a/libavutil/hwcontext_vaapi.h b/libavutil/hwcontext_vaapi.h > index 0b2e071cb3..3e0b54f5e9 100644 > --- a/libavutil/hwcontext_vaapi.h > +++ b/libavutil/hwcontext_vaapi.h > @@ -78,6 +78,10 @@ typedef struct AVVAAPIDeviceContext { > * operations using VAAPI with the same VADisplay. > */ > unsigned int driver_quirks; > + /** > + * The string for the used device > + */ > + char *device_name; This new user-facing API field needs a lot more explanation. The only example you've got is for simple creation via DRM, which sets it to a device path. There are other ways to make a device: * Created via X11 (like ":0"). * Derived from a DRM device (e.g. from kmsgrab). * Manually created by the user (who need not have any path even if they did open via DRM, because they could have given the fd by something else like DRI3). What happens for existing users who have build against the current API without this field and expect it to continue working? I am generally very sceptical that hacking the library API like this is sensible. If you only want it to work in the ffmpeg utility (which is what the current version appears to do), then maybe you would be better off modifying that instead. If this new libmfx really does want to open a new device from the filesystem then you probably want to add new API to libva to supply that information. - 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".