- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- « Previous
- Next »
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Had this issue been fixed? Can anybody share the fix?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Min Gong (Intel) wrote:
Had this issue been fixed? Can anybody share the fix?
Isn't fixed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
:(
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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%.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Beese, Erin wrote:
Any further updates on this issue?
silence... :)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
- Next »