MFXVideoVPP_Init fails -17 with new i7 processor

[Silviu_B]

I have a problem using VPP on a computer with a new i7 chip when I try to use VPP functionality. This is the same error in this older thread, but the Intel representative suggested to start a new thread, so I reporting this problem in a new thread.

Here is the new processor that fails:
Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz

Here is the older processor that worked properly:
Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz

If I used mfxlib.lib from use the older Media SDK (I think it was 2013, MFX_VERSION_MINOR  was 6), VPPInit would succeed. If I linked the program with mfxlib.lib from Media SDK 2014 R2, VPPInit failed -17.

I finally narrowed down the problem: 

• In older Media SDK, MFXInit returned the first handle found from the registry, which was loaded with MFX_IMPL_HARDWARE2.
• In Media SDK 2014 R2, MFXInit gets the first handle from the registry (MFX_IMPL_HARDWARE2), then it gets another handle with the generic MFX_IMPL_HARDWARE. Then it calls qsort, which has a quirk and swaps equal values, which results in the picking the second session (the one created with MFX_IMPL_HARDWARE). This second session which kinda works, but not as well as the proper session initialized with MFX_IMPL_HARDWARE2.

Here is what happens if MFXInit returns a session initialized with MFX_IMPL_HARDWARE:

1. MFXVideoENCODE_Init for a H264 encoder returns MFX_WRN_PARTIAL_ACCELERATION (4)
2. MFXVideoVPP_Init returns -17 (MFX_ERR_DEVICE_FAILED)

If MFXInit returns a session initialized with MFX_IMPL_HARDWARE2, MFXVideoENCODE_Init and MFXVideoVPP_Init return MFX_ERR_NONE.

For some reason, if I put the older processor in another computer, it registers everything as MFX_IMPL_HARDWARE instead of MFX_IMPL_HARDWARE2, even if there is a secondary graphics card in there. I used to have this older processor in this same computer and I remember that it used to require using MFX_IMPL_HARDWARE2 to get hardware acceleration.

I fixed the problem by adding some extra checks at the end of HandleSort and rebuilding mfxlib.lib. Here is the udpated version of HandleSort that corrects this problem (I prefixed the change with “//sb:”):

int HandleSort (const void * plhs, const void * prhs)
{
    const MFX_DISP_HANDLE * lhs = *(const MFX_DISP_HANDLE **)plhs;
    const MFX_DISP_HANDLE * rhs = *(const MFX_DISP_HANDLE **)prhs;

    if (lhs->actualApiVersion < rhs->actualApiVersion)
        return -1;
    if (rhs->actualApiVersion < lhs->actualApiVersion)
        return 1;

    // if versions are equal prefer library with HW
    if (lhs->loadStatus == MFX_WRN_PARTIAL_ACCELERATION && rhs->loadStatus == MFX_ERR_NONE)
        return 1;
    if (lhs->loadStatus == MFX_ERR_NONE && rhs->loadStatus == MFX_WRN_PARTIAL_ACCELERATION)
        return -1;

    //sb: favor the library with the defined storage ID
    if(lhs->storageID == MFX_UNKNOWN_KEY && rhs->storageID != MFX_UNKNOWN_KEY)
       return 1;
    if(lhs->storageID != MFX_UNKNOWN_KEY && rhs->storageID == MFX_UNKNOWN_KEY)
       return -1;

    return 0;
}

I attached a simple project you can use to reproduce this problem. I also attached the logs generated by MFXInit on the computer with the old and new processor.

I am doing all this in Windows 7, using a 32-bit app.

[Jeffrey_M_Intel1]

Thanks for your problem description and reproducer.  We will take a look at this issue and get back to you soon.

[Jeffrey_M_Intel1]

I've set up your reproducer on a similar 6th Generation Core machine which also has an NVidia graphics card.  So far I have not been able to replicate the problem.  MFX_IMPL_HARDWARE_ANY or MFX_IMPL_AUTO_ANY picks the right device with the default/unmodified dispatcher.  However, this is with Windows 10 and Media SDK 2016.

As an additional data point, are the results any different if you install the latest Media SDK and link with that version of libmfx.lib?  Any reason you need the older library?

Thank you for the suggestion for updating the dispatcher search to add StorageID.  We can start looking at dispatcher updates but just to set expectations dispatcher updates are quite likely to come out only for new releases so backporting to 2014 R2 (probably straightforward) would be up to you.  

From your description it sounds like you have a workaround with your dispatcher updates so this isn't blocking your development, correct?

Another option would be to have your application do some system queries at startup to determine which adapter to use if there are other problems with the HARDWARE_ANY search that aren't covered by your workaround.