I'm working on a DirectShow filter using the Media SDK. Of course I'm linking with libmfx.lib. It seems to me that libmfx.lib uses 3 methods to locate the libmfxsw32.dll:
(1) If the Intel Media SDK is installed, it loads the file from there. (2) Or it looks in the path the current process (exe) is started from. (3) Or it uses the windows search path.
In my case I'd like to distribute the libmfxsw32.dll in the directory of my DirectShow filter, which is *not* in the windows search path, and which also doesn't match the exe start path. So in my situation it seems that libmfx.lib isn't able to find libmfxsw32.dll at all. That's a problem.
I'd like to suggest that you improve libmfx.lib to fix this problem. IMHO the very *first* location you should check is the path your own module (the one libmfx.lib was linked into) is stored in. If you're not sure how to find out into which module you're linked, here's how: Call "VirtualQuery(addressOfOneOfYourOwnFunctions)". You'll find the module handle in "mbi.AllocationBase" afterwards.
I understand your reasons for this request, however we currently have no plans to modify the Media SDK dispatcher mechanism to support searching for Media SDK DLL in local DLL folder.We may explore enhancing the dispatcher search algorithm in future revisions of Media SDK, but there are no guarantees.
As a solution I suggest you distribute the Media SDK DLL by copying it to a folder that is in the Windows search path, or add your own folder (where the Media SDK is located) to Windows search path.
Well, using your suggested solutions I can't be sure which dll the MSDK will use. It might be the one I distributed, or it might be a different one. The problem is that I've tested my software with a specific version of the MSDK and I want my software to use exactly the libmfxsw32.dll version I tested with, because only that way I can guarantee perfect stability and functionality.
Besides, I generally dislike installers which copy dlls to funny locations or who add themselves to the Windows search path. That's just not good installer behaviour IMHO.
What happens if I add a "LoadLibrary(myOwnLocalFolder\libmfxsw32.dll)" call before initializing the MSDK? That seems to work just fine here. But I don't have an Intel GPU to test with. Would that LoadLibrary call stop MSDK from being able to use hardware acceleration? Or is it just fine from your point of view to manually load the sw dll? If so, when I'm done and I've closed down everything, is it safe to FreeLibrary(libmfxsw32.dll) again? I'll have to do that since I've loaded it myself, otherwise it will stay loaded forever (due to dll reference count).
The situation is not as problematic as you describe. Different versions of Media SDK (such as 2.0 and 3.0) have different API versions. A developer can intialize the SDK with the minimum required API version and thereby make sure that the corrent verison of the SDK DLL is picked up depending on the level of functionality required.
Anyway, you should be able to manually force load (and unload) of SW library as you describe. However, first check with dispatcher (required to find HW DLL) if HW acceleration is available to allow acceleration on current and future platforms.
Alternatively, a bit mure clunky approach would be to manually modify the PATH on application start to make sure the selected Media SDK DLL gets loaded.
> A developer can intialize the SDK with the minimum > required API version
and thereby make sure that the > corrent verison of the SDK DLL is picked
up depending > on the level of functionality required.
Hmmm... The only way this would work would be for you to manually enumerate the environment PATHs and then check each one separately, loading every libmfxsw32.dll file you find in any of the PATHs until you find one that matches the minimum required API version. Did you actually implement it like that? I have my doubts about that... :o) If you did: my compliments to you!
> Anyway, you should be able to manually force load > (and unload) of SW
library as you describe. However, > first check with dispatcher (required
to find HW DLL) > if HW acceleration is available to allow acceleration > on
current and future platforms.