Media (Intel® Video Processing Library, Intel Media SDK)
Access community support with transcoding, decoding, and encoding in applications using media tools like Intel® oneAPI Video Processing Library and Intel® Media SDK
Announcements
The Intel Media SDK project is no longer active. For continued support and access to new features, Intel Media SDK users are encouraged to read the transition guide on upgrading from Intel® Media SDK to Intel® Video Processing Library (VPL), and to move to VPL as soon as possible.
For more information, see the VPL website.
3058 Discussions

Exception at encoding core, MFXVideoCORE_SyncOperation permanently returns MFX_ERR_UNKNOWN after it

OTorg
New Contributor III
4,045 Views

Application pseudo code:
1. create session
2. create h264 encoder on that session, init it, prepare buffers
3. encode frames from raw nv12-file
4. flush encoder, wait for last output frame
5. release encoder and all resources, except session
6. goto 2

Input file and encoding parameters are the same on every cycle execution. Debug compillation, x86. MFX_IMPL_SOFTWARE only. imsdk 1.7.
After some time after application start (from several minutes to several days, in different runs) i got at debugger output:
"First-chance exception at 0x595798f3 in imsdk_h264enc.exe: 0xC0000005: Access violation reading location 0x000000c0."
And MFXVideoCORE_SyncOperation returns MFX_ERR_UNKNOWN after that, subsequent MFXVideoCORE_SyncOperation calls (with the same arguments) permanently return MFX_ERR_UNKNOWN.

Exception point details:
C:\PLANG\Intel\Media SDK 2013 R2\bin\win32\libmfxsw32.dll, offset 0x001988F3 from section ".text" begin
595798D7 mov ecx,dword ptr [edi+1D34h]
595798DD push edx
595798DE lea edx,[ecx+eax*2]
595798E1 mov eax,dword ptr [esi+20h]
595798E4 lea ecx,[eax+edx*2]
595798E7 mov edx,dword ptr [edi+34h]
595798EA mov ecx,dword ptr [edx+ecx*4]
595798ED mov eax,dword ptr [edi+1B94h]
595798F3 add ecx,dword ptr [eax+0C0h] *********** it is here *********
595798F9 mov edx,dword ptr [esi+3Ch]
595798FC push ecx
595798FD push edx
595798FE push edi
595798FF lea ecx,[ebp+0Bh]
59579902 mov edx,esi

PS:
Now, I realized that there is a little chance that problem is provoked by crt versions conflict (i got "LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs" at build, because of debug application build).
I'll make own mfx_dispatch build with the same settings as at application (debug/mt-dll-crt/vs2010), use it to rebuild application, and run tests again.
I'll write the results here in a couple of days.

0 Kudos
1 Solution
Petter_L_Intel
Employee
4,034 Views

Hi dj_alek,

I've asked my colleague to get back to on this since he explored thie question at an earlier stage.

Regarding the SW DLL exception issue. We plan to resolve the issue in Media SDK 2014, which will be released at the end of this year.

Regards,
Petter

View solution in original post

0 Kudos
69 Replies
celli4
New Contributor I
393 Views

We seem to have a similar problem at my company, using FileVersion 6.15.6.2, Productversion 6.0.0.388 of libmfxsw64.dll, we get a very rare, but reproducable -1/MFX_ERR_UNKNOWN from MFXVideoCORE_SyncOperation.

In our experience the best way to reproduce this issue is to run multiple processes simutaneously under Hyper-V.

It seems to occur about once every two days when running 3x processes under a single HyperV instance.

We unfortunately  don't have a tight redistributable reproduction example at this point in time.

[We are doing transcoding]

We do believe there is a high chance this is an issue in the IMSDK, and would like to see it confirmed/debunked and fixed if found.

It would be extremely helpful if Intel would elucidate what this error means internally, for example are the OS Wait/Event handles returning an error that is unexpected? 

But probably the most important thing to make progress on this, is a tight clean, easy to validate reproduction sample and recipe for reliably reproducing the issue. Ideally based off of one of the last 0.0.3 tutorial samples.  [Here https://goo.gl/Nfrl6U ]

My client will probably have to restart their transcodes as a workaround until this can be confirmed to be an IMSDK issue, or not.

If you are inside of Intel, or outside of Intel and are Interested is coordinating effort to confirm this to be an issue in the IMSDK, please feel free to contact me.  I am dedicating a couple of servers, and some of my time to try to shed some light on this, and get sufficient evidence to get Intel to look at it seriously.

 

0 Kudos
OTorg
New Contributor III
393 Views

camkego wrote:

We do believe there is a high chance this is an issue in the IMSDK, and would like to see it confirmed/debunked and fixed if found.

... reproduction sample ... 

Intel had confirmed (2 years ago) it is IMSDK bug: https://software.intel.com/en-us/forums/intel-media-sdk/topic/475624#comment-1767266

But, as of 06.2015, they have not fixed it.

Simple applications to qiuckly reproduce the issue are here: https://software.intel.com/en-us/forums/intel-media-sdk/topic/475624?page=1#comment-1779278

Have a luck!

0 Kudos
Min_G_Intel
Employee
393 Views

Had this issue been fixed? Can anybody share the fix?

0 Kudos
OTorg
New Contributor III
393 Views

Min Gong (Intel) wrote:

Had this issue been fixed? Can anybody share the fix?

Isn't fixed.

0 Kudos
OTorg
New Contributor III
393 Views

I have checked hardware imsdk implementations. Result is the same (hungs, access violations, crushes, etc).

Tested on:
- imsdk versions 1.8, 1.11, 1.17;
- dx9, dx11;
- x86 and x64;
- win7, win8.1, win10.

:(

0 Kudos
Beese__Erin
Beginner
393 Views

Any further updates on this issue? Is there any way to recover once this occurs? Here is my setup:

One master session with 25 joined child sessions.

H264 encoding

SW Mode

Version 7.0.0.311

I find that my test will run for 10-72 hours before SyncOperation returns MFX_ERR_UNKNOWN. When this occurs, I close/reinitialize the encoder, delete and reallocate the frames, & close/reinitialize the task pool. The encoder appears to recover but at some point I find that the libmfxsw32.dll threads are pinned at 100%.

0 Kudos
OTorg
New Contributor III
393 Views

Beese, Erin wrote:
Any further updates on this issue?

silence... :)

0 Kudos
Reply