Memory leak on mac osx

[ghost]

Hi if i use the receiver example with the fbo or with image the memory is counting up around 1mb/s. Any hints? I use osx 10.13, which shouldn be a problem. Thanks

[leadedge]

I can't find any leak using the NDI "Scan Converter" screen capture full screen 1920x1090 at 60fps for any of the options.

All of these use Openframeworks functions for data exchange. I am using Version 11.0.

Is this limited to the fbo and image options? I would suggest to try receiving to an unsigned char pixel image where you are in control of allocating the receiving buffer.

[leadedge]

I have made some modifications to the addon receiver source files and the example. I can't test with OSX but maybe it could help with your memory leak problem.

[ghost]

This is great, i will check it in the meantime i can confirm that the char pixels do the same. I think that it is a problem with the lib. I only receive around 15fps and i think that the not used frames filling up the buffer. Biut i wil test the new addon now

[ghost]

It is still the same, could it be the framerate and freeing of not used frames? The sender runs at 50fps and the receiver fps at around 15.

[ghost]

Ok, i am one step further. I tested now with different senders and the memory leak only appears if audio and video is sended. If it is only video no memory issue. I tried to use FreeAudioData() but this doesnt solve it.

[leadedge]

Yes I have seen the 15 fps problem. I changed driver fps sync on or off but no difference. I also tried a sender (Spout to NDI) that allow async sending but no change.

Then, after working on it, out of nowhere I achieved half (30/60), so I left it as acceptable. But there is something going on there. Your idea of unused frames filling the buffer might be a clue and I will investigate further. I am interested to know whether you get 30fps with the changes.

Meanwhile at least there was a bug in ReceiveImage by using "setFromExternalPixels", because the source pixels could have been freed before using the pointer again. This was a matter of timing and was not detected.

I will check that the audio buffer is freed.

[ghost]

Thanks for your support! I solved the leak by setting the audio to true by ndiReceiver.NDIreceiver.SetAudio(true);. I will check now your update.

[leadedge]

Thanks to your finding, I fixed the leak. The audio buffer was not freed unless the option was selected. There was the same problem for metadata. The reduced frame rate is still an issue. It's half the sender's rate. I reproduced this using the NDI example receiver code. I will download the latest version of the SDK and try that.

[TroikaTronix]

@leadedge Hey there, Mark from TroikaTronix here. Can you specify the call you had to modify and what changes you made, or point me to a line in the source code? I want to check this in Isadora too. Thanks in advance.

[leadedge]

Hi Mark,

ofxNDIreceive.cpp, lines 1049 and 1050 were swapped, so the received audio buffer was never freed unless the user set audio true. The same applied to lines 882 and 883. Also the metadata buffer release was fixed (lines 1044 and 877).

I still have having problems with receiving at half frame rate of the sender. I posted on the NDI Developer Hub but no reply yet. It could be related to my AMD graphics card and I will try another system with Nvidia.

Meanwhile I modified an NDI sample to eliminate this addon as the possible cause. You can find it here.

[ghost]

The new version works great. Thank you for your support

[leadedge]

OK that's a good outcome. I hope you get good use out of this.