Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I
17 Views

Problem in distribution of Media SDK libraries.

Jump to solution

Dear masters,

      I'm done with my 264 decoder ActiveX component, i.e. OCX, built on top of intel media SDK.Now, I need to distribute it and its dependency to other's PCs(win7) to support their application . So, I made the installation package where libmfxsw32.dll,libmfxsw64.dll and libmfxhw32.dll are all included. After running setup, I was sure that all those files were put into the specified folder of their PC. But, when their application is launched, through the my ocx's log, I saw the Mfx session failed to be initialized. The code snippet is,

sts = m_mfxSession.Init(MFX_IMPL_SOFTWARE, &min_version);

and the value of sts was '-9'.

Is there anything missing in my installation pacckage?

BTW,after I installed the intel media sdk totally, everything is OK.

 

0 Kudos

Accepted Solutions
Highlighted
New Contributor I
17 Views

You do NOT distribute the hw DLL.  First, it makes no sense since it's HW-dependent, and second, DLLs load by name so once a dll is loaded (anypath/xyz.dll) no other DLL with that name xyz.dll can load.  The hw DLL is included in the graphics driver package that the end user has installed.  You do not, and cannot, mess with that.

Distributing a .lib makes no sense, either.  Saying it only works when you do means you don't know what you are doing.

The ONLY thing you could/should include is the SW DLL.  If you don't care to fall back to SW then you don't even need that since the hw DLL has the SW support built-in, so the SW DLL is only for non-recent intel systems (e.g., old Core2, or any AMD), or where the driver package was not installed (some servers, say).

And last, the SDK is for your use in accessing APIs in the *W DLL.  You could, if you wanted, use the original SDK and so long as you don't need to make use of/access APIs only exported by later SDKs (via the import .lib), you could use that very old SDK just fine and still work with an up-to-date gfx driver.

I know this makes no sense to most of you here (not all, but most), from the push-button-GUI-era, but it's a lot simpler in fact than you make it to be.

View solution in original post

0 Kudos
4 Replies
Highlighted
Employee
17 Views

Hi Brooks, 

I was wondering if you have included libmfx.lib in your package. As far as I have used executables on a fresh OS, I have the libmfxsw32.dll,libmfxsw64.dll, libmfxhw32.dll, libmfxsw64.dll and mfxlib.lib. Also if you are using any plugins, please make sure the plugins dll also. Hope that will help.

Thanks,
-Surbhi

 

0 Kudos
Highlighted
New Contributor I
17 Views

Hi, Surbhi

     I added libmfx.lib and igfx_s3dcontrol.lib into my installation package, making them to be placed in application folder. It turns out that the OCX could not work either as before. And then, I changed the destination folder for these 2 libs to system directory( c:\\windows\\system32 ),  and the OCX got to work very well.

    So, thanks a lot for your help! But I am still curious about why the lib files are needed in run-time. As I understood, in general, they are only necesarry for compilation, is it?

 

B.R.

Brooks Li.

0 Kudos
Highlighted
New Contributor I
18 Views

You do NOT distribute the hw DLL.  First, it makes no sense since it's HW-dependent, and second, DLLs load by name so once a dll is loaded (anypath/xyz.dll) no other DLL with that name xyz.dll can load.  The hw DLL is included in the graphics driver package that the end user has installed.  You do not, and cannot, mess with that.

Distributing a .lib makes no sense, either.  Saying it only works when you do means you don't know what you are doing.

The ONLY thing you could/should include is the SW DLL.  If you don't care to fall back to SW then you don't even need that since the hw DLL has the SW support built-in, so the SW DLL is only for non-recent intel systems (e.g., old Core2, or any AMD), or where the driver package was not installed (some servers, say).

And last, the SDK is for your use in accessing APIs in the *W DLL.  You could, if you wanted, use the original SDK and so long as you don't need to make use of/access APIs only exported by later SDKs (via the import .lib), you could use that very old SDK just fine and still work with an up-to-date gfx driver.

I know this makes no sense to most of you here (not all, but most), from the push-button-GUI-era, but it's a lot simpler in fact than you make it to be.

View solution in original post

0 Kudos
Highlighted
New Contributor I
17 Views

Hi,betlet, up to now, I have not got a chance to fully complete my test according to what you said. However, at least, I proved it on one of the machines, in our lab. I deleted  the deployed lib and HW dll, and then the application could still work fine.Probably, you are right.

0 Kudos