Memory leak with 2.006 SpoutSender

[phields]

Memory leak with 2.006 SpoutSender

[leadedge]

Thanks for your attention with this.

I see from your posts on KlakSpout that you disable a line in SpoutDirectX::CreateSharedDX11Texture, but if you enable it, Unity crashes.

if (pTexture) ReleaseDX11Texture(pd3dDevice, pTexture);

Are you building the KlakSpout plugin? I assume that this is not normally a problem. Can you give more details?

What do you mean by "If I use the original SpoutSender"? Is this something to do with KlakSpout or the Spout SDK? Which version of the Spout SDK are you referring to ?

To help with this I need more information to reproduce the problem.

[phields]

Thank you for your prompt response,

Yes, I am trying to compile the KlakSpout plugin.
https://github.com/phields/KlakSpout
After commenting out that line of code, the project can be compiled and work normally. But I haven't figured out why yet.
And I still have this memory leak problem in my branch.

This memory leak occurs in Spout 2.006 and 2.005 versions of SpoutSender.exe with SpoutCam.ax.（both OpenGL and DX version）
KlakSpout uses 2.006 SDK and has the same memory leak issue.
The memory usage of SpoutSender.exe does not grow and the virtual camera host software keeps increasing its memory requests, a phenomenon also seen in software other than OBS Studio.

[leadedge]

I can't use Unity, so what other software have you seen with this problem?

[phields]

I may not have described it clearly, but the SpoutSender.exe in the Spout 2.006 and 2.005 official examples, when used with 2.007 version of SpoutCam64.ax, causes this memory leak problem.

[phields]

I re-tested and found that only the current branch DX version of SpoutCam has the memory leak issue, the OpenGL branch is working fine.

[leadedge]

OK that narrows it down to SpoutCam DirectX version which is a good start.

I will try to reproduce with Magic Music Visuals which I use for testing.

[leadedge]

I could reproduce the memory leak and believe I have fixed the problem. The resource created by OpenSharedResource for shared texture copy was not being released. I have run it for extended periods with any memory increase. New binaries are included. If your testing is still not OK I will keep looking.

[phields]

Great, the memory leak is gone.
But when I change the SpoutSender resolution, the memory from the old shared texture doesn't seem to be recycled.

[leadedge]

When the sender changes resolution, the resource created to access the sender shared texture is released - that's what was causing the leak. There is also a staging texture used to copy from GPU to CPU and that is also released for size change.

But the shared texture itself belongs to the sender. Are you able to check whether the sender releases the shared texture before creating a new one?

Edit -
I just realised that you could be referring to SpoutSender.exe, and stretching the window to resize it. I will have a look at that to make sure the texture is released.

[leadedge]

Try this version

I found a possible problem that the sender's DirectX shared texture was not released from the GL/DX interop before the OpenGL shadowing texture was released. This would only happen if the sender is updated, i.e resizing the demo sender window.

[phields]

You're right! All memory is recycled normally in this sender.
Great.

[leadedge]

I have updated both demo programs in the beta branch. I think we can safely close this one now. I have other things to complete before updating the source code.