If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Extremely high CPU load with NDI Library

SO this NDI camera control application we're developing appears to cause very high CPU load (50-70%) on relatively new machines with i7-8700 processors in them. We're in the process of diagnosing, but I figured I'd check to see if anyone had experienced the same and if there might be some known common causes.

Note: This application uses the NDI library strictly for camera control. There are no video streams coming to, from or through it.

SO this NDI camera control application we're developing appears to cause very high CPU load (50-70%) on relatively new machines with i7-8700 processors in them. We're in the process of diagnosing, but I figured I'd check to see if anyone had experienced the same and if there might be some known common causes.

Note: This application uses the NDI library strictly for camera control. There are no video streams coming to, from or through it.

TIA
Mark

One issue experienced with older NDI libraries, was if you connected a Source, then it was effectively disconnected - so NDI was technically in receive but sitting waiting to get more data, that could cause a 100% CPU Core deadlock. Particularly happens via routed signals where the routing is interrupted.
This appears to have been addressed in later NDI releases.

It sounds like you are sending PTZ (or similar) metadata. Are you limiting how often the data is sent? Without a video or audio stream to clock, NDI will send the metadata stream immediately without any waiting. That can cause a high CPU load due to both the application running frantically, and the network being flooded with a torrent of NDI messages.

By "metadata", do you mean commands? There is no data sent to the cameras unless the user has issued a movement command. The load jumps up as soon as the application is started and the cameras are found and remains high until the application is shut down, regardless of whether any movement commands are being sent. Let me know if that's not what you meant.