Finding an monitoring all network sources

[leadedge]

I am developing am OpenGL application using Openframeworks and C++ and I am having a problem with "NDIlib_find_get_sources".

The "NDIlib_Recv" example creates a finder, waits to find a network source with a 10000msec timeout, then destroys the finder. The result is that it quits the loop as soon as it gets a sender.

First I used the same code, but it always of course breaks as soon as it gets one sender and what I want to do is get all the senders on the network and monitor them as they are added and deleted.

To explain further, I am doing this in the Openframeworks draw cycle which is clocked at 60fps.

Then I kept the example code the same but changed the "NDIlib_find_get_sources" function for zero timeout. But it makes no difference, because again it breaks when it finds the first sender. I assume that is because it is a new finder and it takes time for the finder to discover all sources on the network. The problem is we never know in advance how many senders are on the network.

So then I created a finder and left it rather than destroying it on very cycle. This works just fine and as senders are added, the count increases.

However, when a sender is closed, the count is not reduced and stays at whatever it was. So I can monitor additions but not deletions.

Can anyone help me out on how to monitor the network source additions and removals. The "Video Monitor" application does it just fine and that is that I want to achieve.

 

[John Perkins]

I think you're taking the simple example too literally.

The NDIlib_find_instance_t would probably have a lifetime as long as your application.

Periodically, call NDIlib_find_get_sources. (could be called on a timer, could be a thread, whatever makes sense in your application)

The wait time makes more sense when called on its own thread as it will wait for potential changes up to the timeout limit.

With a wait time, if NDIlib_find_get_sources returns NULL, there were no changes since the last check. If non-NULL, then the list contains the newly found machines, update as needed.

If you aren't on a thread, a wait time of zero just gets a snapshot of all the machines it has found up to that moment. It won't wait looking for changes or tell you if it changed, but it also won't stall your application for the timeout length.

I highly suggest using a separate thread.

Finally destroy your NDIlib_find_instance_t before you exit the application.

 

[leadedge]

Thanks for the quick response.

My reference to the example was by reason of sequence of investigation.

Yes we are considering threads but trying to avoid it to keep it simple.

You say "the list contains the newly found machines" and also "a snapshot of all the machines it has found up to that moment".

What about machines that have been closed. Are they removed from the list?

Yes I destroy the finder and anything else.

 

[John Perkins]

For any one "run" of the application, you don't want to remove machines from the list of known sources.

You have to account for them losing connection. For example, WiFi may have interference and temporarily lose communication.

Especially if you are currently connected to a source that goes missing, you will want to leave it connected so that as soon as it comes back, it will immediately start sending frames to you without having to re-find it and establish a new connection.

As far as I'm aware, all 3rd parties are acting like TriCaster in this regard.

 

[leadedge]

OK, I understand. I will figure out something. Thanks for your replies.