Tractus NDI® Benchmark Tool - Alpha Release

“When I have 10-15 NDI’s coming in and trying to figure out which one is using too much bandwidth.”

Funny how one comment can spark the creation of something new.

Based on feedback from our NDI source browser tool, I started to dive deeper into the internals of NDI.

First, some technical details.

The challenge: How much bandwidth does each source use?

On the surface, the challenge seems simple. For a given time interval, add up the size of frames received and divide by the time interval to get bandwidth used.

It’s not quite that simple though.

First, when you use the NDI SDK, a lot of internals of the video transport are hidden from you. This is awesome for scenarios where you don’t want to focus on colour spaces, frame rates, and establishing connections (i.e. 99% of the time). The NDI SDK is awesome for making it dead simple to get video over IP going.

However, that abstraction comes at a cost. What isn’t exposed in the SDK:

• The IP address of the source we’re connected to
• Whether the source is transmitting NDI or NDI|HX

NDI Source Discovery: mDNS

The good news is that NDI uses Multicast DNS, or mDNS to do device discovery. So, the tool puts a query out to _ndi._tcp.local to find all NDI devices. This was done after I sniffed mDNS traffic using Wireshark.

With the mDNS response, we can get the IP addresses (plural!) from each NDI device. Beware: NDI can use IPv4 or IPv6, so having both is critical.

With the IP addresses for each source, we can measure the bandwidth.

How it Works

At it’s heart, the tool is simple.

• Run an mDNS query to find out the resolved IP address for each NDI source
• Start up a packet capture on every network card
• For any packets incoming from a selected NDI device (i.e. the inbound packet’s IP address is one of the NDI sources), get the packet length
• Once a second, measure how much data was received by each source
• Display that usage in Mbps and MB/s to the user

With each device you select, the tool creates an NDI receiver. It requests video in NDI’s preferred video space. So theoretical performance should be maximized. The tool doesn’t display the frames - it frees them as soon as they’re received. The focus of this tool is pure bandwidth.

Based on the current code, it may take a few seconds for bandwidth readings to stabilize. Sources on the local machine may or may not register a bandwidth reading either.

Warning: Alpha software

I created this app in a day based on prior work. I’ve made it available for rapid testing and feedback. It is not battle-tested nor should be considered final in any way.

Due to the way the tool works, it requires Administrator Privileges for now.

USE AT YOUR OWN RISK. That said, if you do use it, let me know!