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 031E2431FD for ; Wed, 25 May 2022 06:48:14 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 4DA1468B4E4; Wed, 25 May 2022 09:48:11 +0300 (EEST) Received: from tytanium.xyz (82-64-195-121.subs.proxad.net [82.64.195.121]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 094A868B488 for ; Wed, 25 May 2022 09:48:05 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tytanium.xyz; s=mail; t=1653461284; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3rxFiyrauUw64WYnPWkw3chU+BMhYI6AiNslvOvpQ98=; b=Vv1TpWuJvvRe/boAF0WyTiP8BThqGWXlaYEoDmV8NElxw8rWE4hLWrar6Ew50LqXfMdA92 KgV0+spORRCki7YEIQ7dRtfeqCGhyFr9cGQDh+dG/LNhMd08XuN++Cwz2Ez5K8k8ySiBBe ubTIGxbG1wT8320dZ19uBdCW2qxV/a8= Message-ID: <41752e8c-2ba4-36f2-7b2a-f2a9406449e5@tytanium.xyz> Date: Wed, 25 May 2022 08:48:03 +0200 MIME-Version: 1.0 To: ffmpeg-devel@ffmpeg.org References: Content-Language: en-US From: Trystan Mata In-Reply-To: Subject: [FFmpeg-devel] [PATCH v5] avcodec/mfenc: Dynamically load MFPlat.DLL 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: Firstly, thank you for your review. > You shouldn't use win32_dlopen directly (there's no preexisting code that > does that). If you want to use the helpers from w32dlfcn.h, call dlopen > and dlclose, which then redirect to those functions. But here I don't see > any need to use that wrapper when you probably could just call LoadLibrary > directly. (There's no need for using wchar APIs and long path handling and > all that, when it's just given the hardcoded path "mfplat.dll".) Ok, I will switch totally only LoadLibrary calls. > Secondly, this won't probably work as intended if you have two mfenc > instances running at the same time - you'd load the library twice but only > unload it once. To work around that, you can either add some sort of > reference counting around the library, or keep the library reference in a > per-encoder struct. > > In this case I think I would prefer to keep it in a struct. > This is called once per frame at least, right? For such cases I think it > would be much better if we'd keep the function pointer in a struct (which > then would be owned/contained in MFContext) so we don't need to look it up > every time. I completely missed this. I'm not used to dynamic loading. I will fix this by putting back the library handle and function ptrs in the MFContext struct. I think I will put each looked up symbol in the struct. So every MF function is loaded the same way. > This feels a bit messy with the same function defined differently between > the desktop/UWP cases. Wouldn't it be more straightforward to just keep > all the code for the desktop case, and add ifdefs within e.g. > ff_mf_load_library and ff_mf_unload_library, so that those functions are > simple no-ops if building for UWP? I will fix that, thank you again for review. // Trystan _______________________________________________ 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".