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 CAED743201 for ; Wed, 25 May 2022 06:52:49 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B783668B4F1; Wed, 25 May 2022 09:52:47 +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 3B11168B4A0 for ; Wed, 25 May 2022 09:52:41 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tytanium.xyz; s=mail; t=1653461054; 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=Z+4c7nbeKM3STXRftNJ2xvnbFX5GT2CxuFcf4yv4Ohk=; b=ArmXMHqMVOZFrW5O9ioebOvXgEvLTw+hY/uNUqmPjugpDDrmkvKJlnBatSVyxxcMgCZayx 2FBqcay3j2Tv9WEVxf9IjFHzrICiwFoYin6u60v3thf2/tyGeitYsGr/ZqhDcxO5OJSr1k LFJK1rJylgEB6cluPzzbXxJ+I/jJ3Uc= Message-ID: Date: Wed, 25 May 2022 08:44:14 +0200 MIME-Version: 1.0 To: ffmpeg-devel@ffmpeg.org References: Content-Language: en-US From: Trystan Mata In-Reply-To: Subject: Re: [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".