What Is NDI Analysis and Why Should You Use It
Let’s start with a simple question: What is NDI Analysis, and why should you care?
NDI Analysis is a command-line tool for Windows designed to provide detailed diagnostics about any NDI stream on your network. It doesn’t show you the picture, it shows you the numbers: frame timing, data rates, packet consistency, resolution changes, and more.
Now, here’s what’s important to understand:
NDI Analysis does create a full connection to the source; it receives the audio and video stream, just like any NDI receiver. That means it uses bandwidth, and depending on the stream quality, it can also load your system’s network interface and memory bandwidth.
It doesn’t decode the video, so it won’t stress the GPU or CPU as a playback app would, but it does actively process and measure the incoming stream in real time.
So it’s not a passive observer, it’s a full participant in the NDI network.
Why use it?
Because in the world of NDI, everything may look fine, until it doesn’t.
Your video might stutter. Your audio might drift. A stream might randomly fail to connect.
And when that happens,NDI Analysis helps you answer the hard questions:
• Is the stream even arriving?
• Is the frame timing stable?
• Are packets getting delayed or dropped?
• Is the transmitter sending at a consistent rate?
This tool is a must-have if you’re building an NDI-based production environment or troubleshooting a difficult-to-understand problem.
Finding NDI Sources on the Network
Let’s say you’ve just walked into a studio and want to see what NDI sources are available.
You don’t need to launch a monitor app; you just run:
NDIAnalysis.exe /find
AT this point, the application it scans the network and returns a list of active sources. It tells you:
• The source name (like “StudioCam1” or “Scan Converter v2”)
• The host IP address
• Which port it’s using
You can set a custom timeout with /time: option
By default, NDI Analysis will only locate sources in the Public group.
To find sources in other groups, one or more groups can be specified to locate sources in:
NDIAnalysis.exe /find:"Cameras"
NDIAnalysis.exe /find:"Public,Studio 1"
Running a Source Analysis
Now, let’s say you’ve found the source you want to investigate.
Maybe you suspect it’s dropping frames.
Here’s the basic command:
NDIAnalysis.exe /source:"StudioCam1"
Want to limit it to one minute?
NDIAnalysis.exe /source:"StudioCam1" /time:60
Want to test a low-bandwidth version of the stream?
NDIAnalysis.exe /source:"StudioCam1" /lowQ
You can also focus on video only:
NDIAnalysis.exe /source:"StudioCam1" /videoonly
Or just audio:
NDIAnalysis.exe /source:"StudioCam1" /audioonly
There’s also /framecheck, which is great if you suspect something’s wrong with the stream encoding, like missing frames.
Understanding Transmission Timing – Video send vs Video recv
Let’s dig into the most powerful part of NDI Analysis: the timing metrics.
When you analyze a stream, the tool gives you two key values:
Video send (mS): Min=8.72 Avg=16.67 +/- 1.47 Max=24.70
Video recv (mS): Min=11.44 Avg=16.66 +/- 2.50 Max=24.73
These lines contain everything you need to evaluate the health of your NDI stream and, most importantly, to determine where things go wrong.
This value shows how the receiver experiences the stream. Even if the sender is perfect, network issues can wreak havoc here.
You’re still aiming for an average around 16.66 ms, if you're working with a 60 FPS video stream, you want the average close to 16.66 milliseconds, that’s the theoretical time between frames.
A receiver might show:
Avg=16.66 ±2.50
That ±2.50 is the jitter, the standard deviation of the frame interval. In simple terms, it tells you how stable the receiving timing is.
The lower the jitter, the more consistent and predictable the frame is received.
This is one of the most important measures. It represents the frame rate of data received from the network.
In this example, we are watching a 60 Hz video; the frame rate indicates an average frame time of 16.66 ms, which is expected.
Because this is on a real network, the variance is 2.5 ms, a value much smaller than a frame.
If the variance number becomes too large, there might be dropped frames.
All NDI applications and devices should be designed to support frame variance in the range of half the average, which should be the lowest reliable limit that would not require additional buffering or latency to display smoothly.
At 60 Hz, this would require that the maximum reliable zero-latency transfer rates be 16.68 ms +/- 8.34 ms.
The minimum and maximum times are essential; thus, the most significant delivery time (24.70 ms in the example) provides a very important diagnostic tool.
If you see values exceeding 150 ms, it is likely that network frames were dropped, and you should take steps to ensure packet loss is minimized on the network.
It is essential to bear in mind that some NDI sources may not send video frames if no video changes occur.
A perfect example of this behavior is the NDI Scan Converter.
This value shows the timing of frames as reported by the sender itself, right before the frames are handed off to the network.
It’s a direct insight into how consistently the source is generating and delivering video.
If the timing varies a lot, meaning high jitter or unusually long delivery intervals, it likely means the sender is failing to maintain a stable frame rate.
This could be due to system overload, poor encoding performance, or hardware issues.
In this case, even if the receiver also shows dropped or delayed frames, the root cause is clearly at the source.
On the other hand, if the sending times are clean and consistent, but the receiving times are erratic, the issue most likely lies within the network infrastructure, packet loss, congestion, or routing delays.
For a deeper understanding of all available metrics, options, and usage scenarios, refer to the official documentation of the NDI Analysis Tool, which provides comprehensive technical details and examples.
