Analysis
Analyze your connection.
The NDI Analysis tool is designed for expert users to analyze the performance of NDI network connections. It provides crucial statistics about a connection, offering detailed information on available sources and their connection types.
This tool proves valuable in debugging systems and evaluating the causes of encountered problems.
Disclaimers
While NDI Analysis provides detailed statistics, it's important to interpret them judiciously.
In general, if there's no apparent problem, using this tool may be unnecessary. NDI Analysis can identify practically inconsequential deviations. It's crucial to focus efforts where problems are observable.
NDI Analysis offers a wealth of network and stream details, but the human eye remains the best judge of video performance and quality. Real-time analysis by the observer is inherently more tolerant and superior.
In cases where subjective issues are visible, lower-level analysis might be necessary. NDI Analysis serves as a supplementary tool to help understand the root problems in such cases.
In summary, NDI Analysis is a powerful diagnostic tool, but its usage should be targeted and complemented by human observation for a comprehensive understanding of network performance.
Finding all sources on the network
NDI Analysis can be used in order to locate NDI sources on the local network. To achieve this, you should run:
Because it might take a few seconds to locate all sources on a network, you can specify a timeout – i.e., how long NDI Analysis should scan the network. The default timeout is 5 seconds, but you can specify any number you wish. The following example invokes a 10-second timeout for locating sources:
If you want the scanning to finish before the defined timeout, press CTRL+C to force NDI Analysis to exit.
An example output from the finder is outlined below.
Click on each note to open annotations and learn what each element means.
More information on note 5
This does not preclude NDI from using all source and destination NICs for transfer. NDI negotiates all connected IP addresses for any device (both remotely on the sending machine and locally on receiving machines), and spreads traffic across all available paths between them. When a source is actually on the local IP address, NDI does not use external network IPs at all. Rather, a direct loop-back connection is used for improved performance.
Getting source statistics
NDI Analysis implements a special version of NDI that will receive all data from a source and provide a diagnosis on that data. It is important to know that NDIAnalysis does not decode any data. This means that the CPU performance of the host machine does not significantly impact the results shown.
NDI Analysis can thus be considered to correctly measure stream details as they might be received in an ideal receive instance. That is, only upstream CPU performance, network, network infrastructure, and machine network performance have an impact on the results.
To perform an analysis of a source, you could enter the following:
If you want the scanning to finish before the defined timeout, press CTRL+C to force NDI Analysis to exit. Otherwise, to limit the duration of the analysis to just one minute, you could enter the following:
By default, NDI Analysis will request the video stream to be in High Bandwidth format. If you wish to run Analysis in low bandwidth mode, you could enter the following:
The NDI Analysis tool also has a frame checker mode; this is disabled by default. It is mostly useful when there is suspected corruption in the video bitstream. To enable the frame checker mode, you could enter the following:
All of the above modes can be used together. The following is an example run of NDI Analysis.
Click on each note to open annotations and learn what each element means.
More information on note 5 (connection capabilities)
In this example, the source supports record operations, but neither PTZ control nor KVM control is available. A number of additional properties can be reported, and the set of capabilities can be extended in the future. It is possible to determine almost all the capabilities of a PTZ camera and whether these are provided virtually (e.g., virtual pan and scan) or in true physical form (e.g., servos controlling a position). Camera capabilities such as exposure control, iris control, etc., are also reported.
More information on note 8 (format)
The picture aspect ratio is provided as a single floating-point number comprising the frame width divided by height (e.g., a 16:9 image would return 1.78, while 4:3 would return 1.33).
More information on note 9 (audio bitrate)
NDI High Bandwidth uses a very high-quality bitrate stream (often several megabits per second), while NDI HX audio often involves heavier compression at the expense of slightly higher CPU overhead (for instance, AAC audio). The bitrate reflects the measured bitrate (as opposed to a calculated bitrate). This means, for example, that if audio is interrupted for some reason (e.g. some packets are ‘silent’) this is reflected in the value shown.
More information on note 10 (video data rate)
This is mainly in order to preserve the best quality while avoiding unnecessary compression level changes unless warranted for multiple frames. The data rate is a measured value, so if frames are not sent repeatedly, the value is correspondingly reduced. For instance, lower values would occur if a source does not provide all video frames – as sometimes can happen when successive frames are identical.
More information on note 11 (frame size)
In this example, the minimum frame size was 289.90 KB, and the maximum was 320.91 KB. The average frame size in the period measured was 292.33 KB, and the standard deviation was 8.09 KB. The standard deviation can be viewed as an indication of how stable the frame size was. A small value indicates that the size of the frames is very stable, while a large value indicates that frame sizes vary greatly. For relatively constant video, as presented in this example, the variance is very small – meaning that 68% of frames (one standard deviation) would be in the range of 284.24 and 300.42 KB.
More information on note 12 (frame rate data)
In the example above, 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 with computers that are doing other things, the variance is 2.3 ms, a value that is much smaller than a frame. If the variance number becomes too large, there might be dropped frames.
All NDI applications should be designed to support frames within the Nyquist sampling limit, which would mean that any frame variance in the range of half the average 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 would be 16.68 ms +/- 8.34 ms.
The minimum and maximum times are important; thus, the largest delivery time (which is 24 ms in the example) provides a very important diagnostic tool. If you see values that are over 150 ms or so, it is very likely that network frames were dropped, and you should take steps to ensure that there is no packet loss on the network. It is important to bear in mind that some NDI sources might not send video frames if there is no video change occurring. Indeed, the example listed above is from Scan Converter v2, which does not provide new frames when there is no activity on-screen (thus reducing CPU time, GPU time, and bandwidth or network time).
For advanced diagnosis of problems, the video receipt time can be combined with the video sending times described in the next note. It is important to observe these two values when looking at large maximum frame receipt times.
Some key reference times related to video timing are listed below:
| Refresh Rate (Hz) | Frame Time (ms) |
|---|---|
60 | 16.66 |
59.97 | 16.67 |
50 | 20 |
30 | 33.33 |
29.97 | 33.36 |
25 | 40 |
More information on note 13 (time measured)
Since this value measures the rate at which frames are provided to the network, high maximum times would be a clear indication of a sender-side problem – even if the received video frame times indicate frame drops at the receiver. In contrast, reliable sending times but unreliable receipt times denote a problem that is most likely with the network infrastructure.
More information on note 14 (size of audio frames)
The one difference to remember is that the number of bytes taken by each audio packet will depend on the number of audio samples in each audio packet.
For instance, sending 800 sample packets will, on average, result in audio packets that are half the size of sending 1600 sample packets.
Understanding performance
NDI Analysis now includes the ability to write out a CSV file that includes information about the timing of every frame captured. This is enabled at the command line with the following example:
This will then write out a file called “my source.csv” that will include a huge list of every frame received, the time at which it was received, and the details of every frame. An example of this output is illustrated below.
| Time (ms) | dTime (ms) | Timestamp (ms) | Timecode (ms) | X resolution | Y resolution | Frame type | Frame rate | Aspect ratio | Codec |
|---|---|---|---|---|---|---|---|---|---|
24:14.3 | 0 | 1.6004E+16 | 1.6004E+16 | 1920 | 1080 | Progressive | 60 | 1.78 | SpeedHQ Mode 2 |
24:14.3 | 20.7 | 1.6004E+16 | 1.6004E+16 | 1920 | 1080 | Progressive | 60 | 1.78 | SpeedHQ Mode 2 |
24:14.4 | 15.1 | 1.6004E+16 | 1.6004E+16 | 1920 | 1080 | Progressive | 60 | 1.78 | SpeedHQ Mode 2 |
24:14.6 | 279.6 | 1.6004E+16 | 1.6004E+16 | 1920 | 1080 | Progressive | 60 | 1.78 | SpeedHQ Mode 2 |
24:14.7 | 18.2 | 1.6004E+16 | 1.6004E+16 | 1920 | 1080 | Progressive | 60 | 1.78 | SpeedHQ Mode 2 |
24:14.9 | 284 | 1.6004E+16 | 1.6004E+16 | 1920 | 1080 | Progressive | 60 | 1.78 | SpeedHQ Mode 2 |
24:15.0 | 25.9 | 1.6004E+16 | 1.6004E+16 | 1920 | 1080 | Progressive | 60 | 1.78 | SpeedHQ Mode 2 |
24:15.0 | 31.5 | 1.6004E+16 | 1.6004E+16 | 1920 | 1080 | Progressive | 60 | 1.78 | SpeedHQ Mode 2 |
24:15.0 | 16.2 | 1.6004E+16 | 1.6004E+16 | 1920 | 1080 | Progressive | 60 | 1.78 | SpeedHQ Mode 2 |
24:15.0 | 16.2 | 1.6004E+16 | 1.6004E+16 | 1920 | 1080 | Progressive | 60 | 1.78 | SpeedHQ Mode 2 |
24:15.1 | 31.7 | 1.6004E+16 | 1.6004E+16 | 1920 | 1080 | Progressive | 60 | 1.78 | SpeedHQ Mode 2 |
24:15.1 | 32 | 1.6004E+16 | 1.6004E+16 | 1920 | 1080 | Progressive | 60 | 1.78 | SpeedHQ Mode 2 |
24:15.1 | 16.1 | 1.6004E+16 | 1.6004E+16 | 1920 | 1080 | Progressive | 60 | 1.78 | SpeedHQ Mode 2 |
24:15.2 | 45.7 | 1.6004E+16 | 1.6004E+16 | 1920 | 1080 | Progressive | 60 | 1.78 | SpeedHQ Mode 2 |
This is valuable to determine why you are seeing problems when sending video over the network.
By dumping the CSV data at two different locations on the network (e.g., you can capture it on the sending machine and also on the receiving machine) and then looking at the “timestamp” data on each frame, you can:
Locate frames that exactly match between different locations and verify whether any frames are dropped (the timestamp is present on the sender side but not on the receiver side).
Check if the frames are delivered late (measuring the dTime).
There is always some variability on most typical networks. So, some level of jitter should be expected, but if there are large timing hits, then there clearly is something on the network that is stopping the smooth flow of packets (e.g., congestion control on a router).
Last updated