NDI iOS SDK leaking memory

Ninakadin

New member
I have created a functionality for one of our iOS apps to select an NDI source and display the video on iPhone / iPad using NDI Advanced SDK v5 for Apple .
I discovered a steadily growing memory usage, so I investigated it by reducing the code to a minimum and checking the allocations with Instruments.
It turns out that for every video frame there is a 144 Byte memory block allocated that is not freed anymore. Sounds not much, but around 15 MB per hour (at 30 fps) is not nothing.

I do standard setup as in the examples:
• NDIlib_find_create_v2()
• NDIlib_find_get_current_sources()
• NDIlib_recv_create_v3() with format NDIlib_recv_color_format_RGBX_RGBA, allow_video_fields = true
• NDIlib_recv_connect
I can provide the full source if required.

My minimum loop doing nothing except to to call NDIlib_recv_capture_v2 (on its own thread):

- (void) receiveFrames
{
while(!isStopped)
{
NDIlib_frame_type_e type = NDIlib_recv_capture_v2(pNDI_recv, NULL, NULL, NULL, 1000);
}
}

So, I don't request video, audio or meta data, but still there is this 144 Bytes leak. It is a call to CMBlockBufferCreateWithMemoryBlock from the library, to be exact:
Processing::NDI::Codecs::details::video_codec_impl::decode_h264::decode_packet(NDI_recv_video_header_v2 const&, std::__1::pair<unsigned char*, long>)

See screenshot of Instruments below.

I don't know whether this is the right place to post it. Hopefully someone from SDK team looks into it.

Cheers,
Nina
 

Attachments

  • Screenshot_Instruments.png
    Screenshot_Instruments.png
    913.2 KB · Views: 57

Jarno

Post-LW Engineer
So this also happens if you do get the video frame and free it with NDIlib_recv_free_video_v2() ?
I'm not a Mac developer, but at first glance it does look a buffer isn't being freed in the mac-specific h264 decoder. I suggest you contact [email protected] with your findings.

---JvdL---
 

Ninakadin

New member
@abdulrehmanashraf87 No, I haven't contacted them yet, since there are much bigger problems with the iOS SDK. For many devices the SDK does not deliver any images at all, it is useless if you communicate to cameras directly. You receive video from NewTek switchers, but for our app this was not the goal. So we reimplemented the whole stuff on macOS. Our iOS apps are on hold until NewTek delivers a functional SDK. But I don't think they really care, just take a look at the poor examples contained in the SDK. I'm pretty sure they are aware of it. You can take a look at other iOS apps, they also can't deliver video from many cameras, e.g. Canon or Marshall.
 
@abdulrehmanashraf87 No, I haven't contacted them yet, since there are much bigger problems with the iOS SDK. For many devices the SDK does not deliver any images at all, it is useless if you communicate to cameras directly. You receive video from NewTek switchers, but for our app this was not the goal. So we reimplemented the whole stuff on macOS. Our iOS apps are on hold until NewTek delivers a functional SDK. But I don't think they really care, just take a look at the poor examples contained in the SDK. I'm pretty sure they are aware of it. You can take a look at other iOS apps, they also can't deliver video from many cameras, e.g. Canon or Marshall.
What's different about Canon and Marshall compared to other NDI HX sources?
 
Top Bottom