DXVA enabled hardware decoding fails on D3D Reset

[Mark_M_2]

After following the D3D decoding sample from the Media SDK I was quickly able to integrate the hardware decoding capabilities of the Media SDK using D3D surfaces with our existing software framework.  To enable the most efficient use of resources and avoid costly memory copies from the surface and back in DirectX (i.e. memcpy of the entire decoded frame) the D3D device that is passed to the Intel Media SDK is the D3D device to which we render the decoded surface.

In other words, this allows us to just display the decoded surface in our Direct3D render viewport - which is very efficient.  This is where we diverge from the D3D samples from the Media SDK as in they create their own D3D device, whereas for us to be able to share the decoding/rendering surfaces we need to pass our D3D device in to the DXVA2CreateDirect3DDeviceManager9() function, and then the device manager is passed into the Media SDK via SetHandle().

For us this means CPU usage on Intel boards where the HW decoding is available is now down to near < 10% of system, which is an excellent result.  However there is one problem.

If the user re-sizes our viewport is it necessary for us to perform a D3D device reset, to take into account the new width/height of the viewport.  Using SharpDX our code looks like this:

var pp = GetPresentParameters(viewportWidth, viewportHeight);
mDevice.Reset(ref pp);

Where mDevice is the C# wrapper for our D3D device.  Unfortunately, at this point - only when using hardware decoding with the Media SDK - this call fails with HRESULT = 0x8876086C (D3DERR_INVALIDCALL).

From this point on neither rendering nor decoding work.

We have had issues with this general DirectX error on D3D device reset when we have previously not released D3D surfaces, however the pool of surfaces allocated by the simple_alloc() - taken from the Media SDK samples - have simple_free() called on them before trying to execute the D3D device reset.

On a systems using the Media SDK *software* decoding, this is sufficient to allow the D3D device reset to complete OK, however it does not appear this is sufficient when using the Media SDK *hardware* decoding - and we can only think there must be some missing release/close procedure that is necessary to able the D3D device reset to complete OK in this case.

With absolutely no help from DirectX, by way of their silly D3DERR_INVALIDCALL error (which is used far too much IMHO) we are at a loss to know what to do?

Mark

[Mark_M_2]

Just an update, I managed to come up potentially with a work-around (as it's not stress-tested yet).  The work-around is basically to close the entire decoding session down before attempting the reset on the D3D device, *everything*, and then re-starting the entire decoding session after the reset.

This appears to work, although it does seem a little brute-force but in the absence of any other alternative I guess this could do.

[Anthony_P_Intel]

HI Mark,

The Media SDK libraries use the supplied D3D device (when you call "SetHandle") and OS is aware the use has not been closed when you attempt to reset the device.  Your workaround (to close MFX session and open a new one) is the current recommended process when D3D9 Reset occurs.