Releasing Decoder COM references to ID3D11Device?

Releasing Decoder COM references to ID3D11Device?

I'm trying to completely deinitialize the graphical portion of our application and free all related memory, but am having a hard time figuring out what needs to be done to release the references to the ID3D11Device that seem to accumulate on (initializing and) using a decoder.

If I go through the decoder initialization procedure and call ProcessHeader() and DecodeFrameAsync on the header info, and then deinitialize it all (per the Sample Decode example), there are no lingering COM references when I subsequently release the ID3D11Device. If, however, I initialize the decoder and proceed through to a call to DecodeFrameAsync, then immediately afterward deinitialize everything and attempt to release the ID3D11Device, it retains a reference. But only the one reference, no matter how many times DecodeFrameAsync is called (though an additional reference appears for every decoder/decoder session initialized and deinitialized)

I can't find anything much in the docs about Releasing anything other than a couple handle-related items. I've tried reinterpreting the frame output by DecodeFrameAsync as an ID3DTexture2D and calling Release() on that, and not too surprisingly this results in undefined/buggy behavior. Is there anything else I should be doing beyond the deinitialization routines in Sample Decode? Or any other insight you might have?

Thanks,

James

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi James,

I looked into DX11 resources handing in the Media SDK sample_decode sample but I do not encounter any resource leaks. DX11 debug mechanism does not report any leaking resources at the termination of the application.

Can you provide a some more details on what specific DX11 debugging info you are seeing that indicates a resource leak?
Also, do you see the issue using unmodified sample_decode sample? 

Regards,
Petter 

Hey Petter,

Thanks for looking into this. I think I've got it resolved now -- it looks like it may have been related to either an older Intel graphics driver, or the fact that we were using our own D3D11 device (instead of that mysterious CD3D11Device wrapper class) and hadn't enabled DX11 multithreading mode.

We had been on I think the 2857 Intel driver. I upgraded a test machine to the latest driver (2932) to see if that made a difference, and immediately the MFXVideoSession::SetHandle routine started failing. I went back and read more carefully through the current MediaSDK manual, and noticed that it says an application is required to set multithreading mode for the D3D11 device passed in to the SDK session.

Enabling multithreading mode fixed the failure when calling SetHandle on our D3D11 device, and it also appears to have resolved the lingering COM reference issue (at least for the latest driver, which is fine by me). I'm guessing something in there wasn't being properly synchronized during deinitalization, in the absence of multithreading mode.

Thanks,

James

Hi James,

glad to hear you found a solution.

Regards,
Petter 

Leave a Comment

Please sign in to add a comment. Not a member? Join today