2019 R1 crashes on MFXVideoSession::Init on 3rd generation processors

[Mark_S_1]

I am compiling the mfx_dispatch code that is distributed along with the Intel Media SDK 2019, and there is a bug when using it with 3rd generation processors that was not in the 2018 R2 sdk.

Line 213 of mfx_dispatcher.cpp checks whether it should call MFXInit or MFXInitEx by checking if the MFXInitEx entry in the MFX_DISP_HANDLE.callTable object is null. 

In 2019 R1, mfx_dispatcher.cpp was changed so that line 63 now reads:

    if (MFX_ERR_NONE != mfxRes)

instead of:

    if (MFX_ERR_NONE == mfxRes)

This means that when MFX_DISP_HANDLE::Close is called, the callTable variable is not reset, and so it is full of now invalid function pointers.  If the MFX_DISP_HANDLE::LoadSelectedDLL is called on a previously closed object, as main.cpp from the dispatcher does, you can end up with a callTable with invalid pointers in it.  This means the check on line 213 of mx_dipsatcher.cpp thinks it should call MFXInitEx when it shouldn't, and the program crashes.

An easy fix would be to reset the callTable object in the MFX_DISP_HANDLE::UnLoadSelectedDLL() method, but I wasn't sure if there would be any repercussions to doing that, that I wasn't aware of.

[Nikita_P_Intel1]

Hi Mark,

Thank you for the issue report.

Could you please reproduce it with MSDK samples and share the cmd.

Also share please graphics driver version and OS version. 

[Artur_M_]

Hi Nikita,

We are also seeing the issue with this init call crashing in our applications. i have tried to run the sample_decode from 2019 and it seems to work. However when i ran the mediasdk_sys_analyzer tool i got output attached image.

Also attached is the tracer log of a startup of our application that results in a crash.

you can see the details of OS and driver version on the image of the analyser output.

There is an issue with the latest intel SDK 2019 R1 and combination of the current drivers for this gen of CPU.

Kind regards,

Artur Magaljan.

[Mark_L_Intel1]

Hi Mark,

Could you give use your reproducer?

I tried Artur's reproducer on Skylake and but I can't reproduce it. So it seems to be on 3rd generation processor only.

Mark Liu

[Ramashankar]

[URGENT]

Hi Everyone,

I am also facing this crash issue in my environment. I have a Windows10 laptop (having CPU i5-3337U & Intel HD Graphics 4000) and a Windows7 laptop (having 3rd gen CPU n graphics card). On both these laptop, my application is crashing as soon as I call MFXInit(). I am using Intel SDK 2019R1.

Does anyone of you has its fix?

Some strange/contradicting observations:
1. Sample_decode exe works fine on these laptops.

2. I created an independent and small app using 2019R1 sdk in which i just call MFXInit(). It also works fine.

3. My product's actual application works well on these laptop if I compile it using sdk 2018R1, but it crashes if I compile it using sdk 2019R1.  Crash event says:

Faulting module name: igdumdim32.dll_unloaded, version: 0.0.0.0, time stamp: 0x5376e31a
Exception code: 0xc0000005
Fault offset: 0x5576d320

I am going to try the work around what Mark S. has suggested in first post, but at the same time I am also in doubt of any side effect due to this.

Any suggestion/fix/work around on this is most welcome as I am in urgent need of its fix. Let me know if I need to provide any further info on this issue.

Thanks.

[Nikita_P_Intel1]

Hi Ramashankar,

This issue has been fixed in dispatcher on Media SDK's GitHub

https://github.com/Intel-Media-SDK/MediaSDK

So I suggest you to use dispatcher and API headers from there. You will need to rebuild dispatcher from source, please see these wiki pages for help:

https://github.com/Intel-Media-SDK/MediaSDK/wiki/Media-SDK-dispatcher-for-Windows

https://github.com/Intel-Media-SDK/MediaSDK/wiki/Build-Media-SDK-on-Windows

Thanks,

Nikita

[Ramashankar]

Hi Nikita,

Thanks a lot for quick response. 

So I suggest you to use dispatcher and API headers from there. You will need to rebuild dispatcher from source, please see these wiki pages for help:

Sure, I will check this dispatcher code.

Thanks, 

[Ramashankar]

Hi Nikita,

I used the latest dispatcher code and headers from GitHub and it is not crashing now. But I am facing another issue of frame corruption while encoding and RGB frame into H264 with this new code base. I doubt that issue is in RGB to NV12 conversion by VPP because if I do direct encode from NV12 to H264 then it works fine.

Please have a look on snapshot of these input and output frame. Input_frame.jpg is snapshot of input rgb32 frame of 1920x1080 dimension, output_frame.jpg is snapshot of encoded h264 file. Output farme is actually stretched version of one third of width 1920 and  full 1080 height.

Thanks, 

[Ramashankar]

Hi Nikita and all.

This frame corruption issue has been corrected, it was due to an error in my code in vpp usage. So finally it is working fine in all scenario.

Now, I would like to get confirmation on following:

1. Can I consider this Github's latest codebase of dispatcher & all headers safe, to be used in my product? I mean is it stable version?

Sorry to have this doubt as I have used only officially released version of intel media sdk (like 2018R1 or 2019R1) till now.

Thanks,

[Dmitry_E_Intel]

Hi Ramashankar,

Thanks for good news!

You asked a good question. For now please consider MediaSDK Windows developer releases (like 2018R1 or 2019R1) as the only official distribution of the dispatcher and API headers for Windows. API headers posted at GitHub is stable (sometimes it's even newer than API shared in Windows dev packages). MediaSDK from API perspective was and remains a cross-OS, backward compatible library. But we don't guarantee that the dispatcher posted at GiHub is the latest one. At least for now. Plus when posting new API at GitHub we don't describe starting from which Intel Windows graphics driver release this particular API is supported. If something in this process changes, we'll post this info somewhere (IDZ or GitHub).

Regards,

Dmitry

[Mark_S_1]

Looking at the new code on GitHub, the fix for the original issue was to change the line in mfx_dispatcher.cc (line 63 in the 2019 R1 release, line 70 in the gitbub version) back to

   if (MFX_ERR_NONE == mfxRes)

as it was in the 2018 R2 release, so I just made that change manually in my 2019 R1 dispatcher code.