Tractus NDI® Benchmark Tool - A Big Update

“I tried the tool. It shows the sources, but not any data.”

Fellow audio/visual and events professional Morten Stensland and I were chatting in the Twitter DMs. He had downloaded my NDI Benchmark Tool, but for some reason, it wasn’t working on his machine.

For reference, Morten is the founder of Presentation Tools. He makes awesome tools like Auto Presentation Switcher and CueTimer. Tools that make life easy for speakers and audio/visual producers at live events.

Like me, he’s an audio/visual tech, and a programmer.

Morten was kind enough to hop on a Zoom call with me where we debugged the NDI Benchmark Tool in real time. An adjustment here, a code change there, and we discovered something odd.

mDNS - How NDI Devices Find One Another

Back when I was first working on this tool, I needed to see how NDI devices found each other. I took a detour to make the mDNS Explorer. In a nutshell, NDI sources use mDNS to announce themselves to other NDI devices on a network.

Since the NDI SDK does not reveal the IP address of the transmitting source, we needed to determine this ourselves. The NDI Benchmark tool combines two ideas - network packet analysis and mDNS.

When we receive a network packet, we check to see if it’s from an NDI device. We do this by comparing the incoming IP address to the known IPs of each NDI source. If there’s a match, and the port range is within the known NDI port range, we assume the packet is an NDI packet.

What are the known ports for NDI? The NDI networking best practice whitepaper is a great resource for this. In general, we look for ports 5959 to 7999. It’s a bit of a hack, but it works.

When I was debugging the Benchmark tool, I used the mDNS Explorer. What I noticed on Morten’s machine is that his NDI sources weren’t sending their IP address in the “Answers” part of the mDNS packet.

mDNS Records - Answers, Authority Records, and Additional Records

Inside each mDNS answer packet are three types of record collections: Answers, Authority Records, and Additional Records.

Each of these record collections can all hold resource records, such as the A or AAAA records (IP addresses) of a device. In the mDNS Explorer and the Benchmark tool, we were only looking at the Answers field for details.

It turns out that on Morten’s machines, the Additional Records field had the A and AAAA records.

A quick bit of patching later and both tools were updated. And now it works on Morten’s machine.

Ports and Protocols

In the latest release, I’ve patched some of the mDNS resolution issues. In addition, I’ve added display of the ports and protocols seen during packet capture.

NDI devices can use TCP, UDP, Reliable UDP, and Multi-TCP for sending data. In my experience with the tool, I’ve seen some devices switch their transmission mode on the fly - from Reliable UDP to TCP and back again. To help determine what each device is doing, I added columns that display which ports have been used to transmit NDI data - in particular, I saw this on Scan Converter for Mac.

These can be cross-referenced against the NDI port list along with the seen protocols to get an idea of which protocol is being used by each source. The following table was pulled from the NDI Networking whitepaper.

Port|Type 5959|TCP - for NDI Discovery server 5960|TCP - remote sources 5961+|TCP - NDI stream transmission 5960+|UDP - NDI 5 stream transmission 6960+|TCP or UDP - NDI stream transmission using Multi-TCP or UDP receiving 7960+|TCP or UDP - NDI stream reception using Multi-TCP, unicast UDP, or Multicast UDP sending

With the protocols seen plus the ports used, you should be able to get a sense of what protocols and transmission modes your NDI sources are using.

Limitations

During my testing with Morten, we did discover a limitation of the tool, which will be addressed in the future.

If a computer is transmitting multiple NDI sources, we cannot tell which packets belong to which source. For something like an NDI camera or NDI converter, this is not a problem - in general, one device = one NDI source. But if you do capture multiple NDI sources from the same machine, their bandwidth will be aggregated in one of the sources.

I do plan to change the output to display the bandwidth used by each device, and if possible, by source one day.

In addition, since we are scanning inbound packets, you should stop any other NDI receivers (such as Studio Monitor or OBS). Otherwise you may get double-counting. We are just scanning inbound packets.