Monday, August 20, 2012 12:03 AM
First, I'm calling this a bug for lack of better understanding, but it's a scenario that worked in Release Preview, but no longer works in RTM reliably (gives unexpected, fatal, HRESULTs; few times it hung the GPU driver). Could be GPU drivers, but one is an NVIDIA 8800 GTX with Win8 WHQL drivers. The other is the Samsung BUILD tablet.
Steps to reproduce:
1.) Create a D3D 11 Device, using any D3D_FEATURE_LEVEL_9X. FEATURE_LEVEL_10_0 and higher yield different, but breaking issues also. Use 0 for the D3D11_CREATE_XYZ flags. D3D11_CREATE_DEVICE_SINGLETHREADED gives more reliable results, but is still very spotty.
2.) Create a IMFSourceReader with attributes of: MF_SOURCE_READER_D3D_MANAGER and an initialized IMFDXGIManager with the D3D 11 device. MF_SOURCE_READER_ENABLE_ADVANCED_VIDEO_PROCESSING set to TRUE. Open up an h264 file. I have been using these (480p, 720p, 1080p)
3.) Create an MFCreateMediaType and set: MF_MT_MAJOR_TYPE to MFMediaType_Video. MF_MT_SUBTYPE to MFVideoFormat_RGB32.
4.) Set the media type by: sourceReader->SetCurrentMediaType(myVideoStreamIndex, nullptr, mediaType);
6.) In a tight loop, run sourceReader->ReadNextSample(...)
Symptoms on NVIDIA 8800 GTX:
1.) ReadSample(...) will return with (usually after decoding many samples): 0x887a0005 : The GPU device instance has been suspended. Use GetDeviceRemovedReason to determine the appropriate action. The "device->GetDeviceRemovedReason()" returns HRESULT 0x887a0020 AKA DXGI_ERROR_DRIVER_INTERNAL_ERROR. This usually happens on FEATURE_LEVEL_10 and higher with D3D11_CREATE_DEVICE_SINGLETHREADED.
2.) ReadSample(...) will execute fine, but the debug output window will read: Microsoft C++ exception: _com_error at memory location 0x000000030E17F238 for every ReadSample(...) called. Most of the time this decodes the entire file fine, but the device has to be FEATURE_LEVEL_9 (not 10 or higher) and D3D11_CREATE_DEVICE_SINGLETHREADED has to be set.
Symptoms on BUILD tablet (stock GPU drivers) are a bit better:
With FEATURE_LEVEL_10 and DEVICE_SINGLETHREADED, it seems to work reliably. At FEATURE_LEVEL_9, it will usually decode at least 30 - 50 frames before ReadSample(...) simply returns E_FAIL. Without DEVICE_SINGLETHREADED on a 9 feature level device, ReadSample(..) will reliably just hang the thread.
I can work up an repro, but it may take a day or two as it's part of a larger project. Please feel free to email me at jeremiah.morrill(at)gmail as I don't want to make it public.
Of course this could not be a bug at all and just incorrect usage from me. But it seemed to work fine in Release Preview...
Thanks for any help on this!
- Edited by jmorrillMVP Monday, August 20, 2012 12:16 AM
Monday, August 20, 2012 8:14 PM
The solution to this is to QI the ID3D11Device for the ID3D10Multithread (Metro safe) device and set the ID3D10MultiThread::SetMultithreadProtect(TRUE)
This is documented here: http://msdn.microsoft.com/en-us/library/windows/desktop/hh162912(v=vs.85).aspx
Thanks for everyone involved in helping with this!
- Marked As Answer by jmorrillMVP Monday, August 20, 2012 8:14 PM
Tuesday, August 21, 2012 9:07 AMModerator
Thanks for sharing the solution.
Jesse Jiang [MSFT]
MSDN Community Support | Feedback to us