White Paper (PDF)
This White Paper offers a compressed overview of NDI: its fundamental principles, technological features, protocols, and settings. It is updated in real-time by the NDI team to reflect the most recent developments to our Core Tech Platform. The current version of NDI is 6.1.
Contents
Discovery & Registration
Zero configuration in AV signal distribution
One of the biggest issues in AV distribution in the IP world is that equipment is not identifiable by its physical connection. In networking, every connected device needs to have a unique address so another device, hardware, and applications can reach it.
However, the network physical connection is dynamic and not related at all to the equipment address. For that reason, in a large network with hundreds (or thousands) of devices with addresses, it becomes difficult to find and interconnect equipment. NDI offers two different options for a zero-configuration discovery and registration: mDNS and Discovery Service.
mDNS
MAC (Media Access Control) address refers to a unique physical address identifying a network node. Sending and receiving video streams across an IP network requires applications that support video and can discover receiving applications that are looking for video.
NDI resolves host names to IP addresses over the LAN and does so automatically. When you start an application that sends NDI, the devices that can receive NDI become aware instantaneously. While this is a typical function on almost all networks, there are some cases where it is important to know how this works to properly configure networks utilizing managed data flow protocols.
By default, NDI utilizes mDNS (multicast Domain Name System) to create the zero-configuration environment for discovery. This service sends an IP multicast message that asks the host to identify itself. The target machine then multicasts a message that includes its own IP address. This multicast is seen by all NDI-receiving machines on the subnet, which then use the information in that message to update their own caches.
These multicast queries are sent to a multicast address, and thus, no single device is required to have global knowledge.
When a service or device sees a query for any service it recognizes, it provides a DNS response with the information from its cache. The primary benefit of using mDNS is that it requires little or no administration to set up. Unless the network is specifically configured not to allow mDNS, NDI sources will be discovered. This format works when no infrastructure is present and can span infrastructure failures.
The mDNS Ethernet frame is a multicast UDP packet that broadcasts to:
MAC Adress
01:00:5E:00:00:FB (for IPv4)
IPv4 Address
224.0.0.251
UDP Port
5353
Choosing the network location type on Windows devices is critical for the successful discovery and registration of NDI. Typically, the first time a Windows machine is connected to a network, a dialog window appears that allows the user to choose the network location type: Private or Public. By default, Windows sets a new network location to Public.
This location is designed to keep machines from being visible and responding to broadcast pings. This location type also affects mDNS responses and keeps NDI video streams from being discovered and registered on the network.
Network locations should be set to Private for successful discovery and registration of NDI. The Domain network location is used for domain networks, such as those at enterprise workplaces. The network administrator controls this type of network location, and it cannot be selected or changed. In this type of configuration, mDNS discovery must be allowed at the domain level. Because mDNS uses a link-local multicast address, its capacity is limited to a single physical or logical LAN.
Discovery Service
NDI Discovery server is a command line application available for Windows, MacOS, and Linux. The NDI Discovery service is designed to allow you to replace the automatic discovery NDI uses with a server that operates as a centralized registry of NDI sources. This can be very helpful for installations where you wish to avoid having significant mDNS traffic for a large number of sources. It can also be useful when multicast is not possible or desirable; it is very common for cloud computing services not to allow multicast traffic. When using the Discovery service, NDI can operate entirely in unicast mode and thus in almost any installation. The Discovery server supports all NDI functionality, including NDI groups. Clients should be configured to connect with the Discovery service instead of using mDNS to locate sources.
When there is a Discovery server, NDI applications will use both mDNS and the Discovery server to find and receive sources on the local network that are not on machines configured to use discovery.
For senders, if a Discovery service is specified, then mDNS will not be used; these sources will only be visible to other finders and receivers configured to use the Discovery server.
To configure the Discovery service for NDI clients, you may use Access Manager (included in the NDI Tools Core Suite) to enter the IP address of the Discovery server machine.
Within NDI version 5, there is full support for redundant NDI Discovery servers. When configuring a Discovery server, it is possible to specify a comma-delimited list of servers (e.g., “192.168.10.10, 192.168.10.12”), and then they will all be used simultaneously. If one of these servers then goes down, as long as one remains active, then all sources will always remain visible, no matter what the others do, then all sources can be seen.
This multiple-server capability can also be used to ensure entirely separate servers to allow sources to be broken into separate groups, which can serve many workflows or security needs.
Once two NDI devices have discovered each other on the network, video can be passed from the sending device to the receiving device. After the compression of the video, the NDI sending device opens a session to the receiving NDI device. At this point, we have two endpoints that consist of an IP address and a port number.
In Windows and MacOS, the Discovery Server addresses are configured in the Advanced Feature Tab. On Linux, however, the addresses of the NDI Discovery Servers can be manually added in the NDI configuration file, which is stored in a hidden folder named ".ndi" within the home directory of the effective user. The configuration file is named "ndi-config.v1.json".
Here is the way to manually set up the Discovery Service in the configuration file:
Copy
NDI Discovery Service to control devices' discoverability.
As mentioned above, with NDI 5, we enabled support for multiple NDI Discovery Servers. NDI Receivers can now specify a comma-delimited list of Discovery Servers (e.g., "192.168.25.10, 192.168.25.12"), and they will all operate simultaneously.
Moreover, an NDI Discovery Server can be connected to multiple network interfaces and supports multiple subnets. Using multiple servers and subnets allows sources to be organized into distinct areas. These areas can cater to various workflows and security requirements.
Here is an example that explains how multiple Discovery Servers can be used for control device discoverability:
Spinning up or shutting down the Discovery Servers with IP Address 192.168.25.243 - 192.168.25.244 - 192.168.25.245 will turn on or off discoverability between the 3 NDI areas.
The example above is related to multiple Discovery Servers in a single subnet.
However, the Discovery Server can be connected and shared between different subnets.
Discovery Servers can be easily deployed on Linux-based virtual machines, and the process of spinning up or shutting down Discovery Servers can be efficiently automated and managed by solutions like Terraform.
Manual Connection
One approach to manually interconnect NDI devices is to specify the IP address of the transmitter in the receiver.
In Windows and MacOS, this can be achieved using the NDI Access Manager in the External Sources feature. Several NDI hardware decoders also support this functionality.
For Linux, the IP addresses of NDI senders can be added manually in the NDI configuration file called "ndi-config.v1.json." This file is in the home directory of the user currently logged in.
Specifying the IP address of an NDI source allows the receiver to receive NDI sources that are in a different subnet and may not be discoverable by mDNS (Multicast DNS). This method enables the reception of NDI sources that might be otherwise inaccessible due to network configurations or limitations.
In Linux manual connections can be added in the NDI configuration file located in the home directory of the effective user: "ndi-config.v1.json"
Here is the way to manually set up NDI sources in the configuration file:
"networks": { "ips": "192.168.123.200,10.10.123.22,", "discovery": "",
NDI Groups
NDI groups enhance the efficiency and management of NDI-based workflows by providing a structured way to organize and control the visibility and access of NDI sources and destinations within a network.
NDI devices support two different kinds of Groups: Send and Receive.
A device can be part of different Groups, some Groups only in the Send or Receive mode:
Scenarios
In this scenario, NDI Device 01 is sending discovery information to Groups 02 and 04. Devices part of the Receive Groups 02 and 04 can discover and receive NDI streams from Device 01.
NDI Device 02 is sending discovery information in Groups: Public, 01, 02, and 04.
NDI Device 03 is sending discovery information in Groups: Public and 03.
There are different ways to define Groups in NDI Devices:
In MS Windows and MacOS, Groups are defined in the NDI Access Manager, which is part of the free NDI Tools:
The Groups string for each Send and Receive operation must not exceed 248 bytes in length, which means that the total length of the combined Group names should not exceed 248 characters.
In Linux, NDI Groups can be defined in the NDI configuration file located in the home directory of the effective user: "ndi-config.v1.json"
Here is the way to configure Groups in the configuration file:
}, "groups": { "send": "Public", "recv": "Public,Group 01,Group 02" },
Hardware NDI Devices must support NDI Groups to be compliant with the NDI standard specifications.
Here are some examples of hardware devices with NDI Groups support:
NDI Protocols
Reliable UDP – NDI 5
In NDI version 5 the default communication mechanism is a Reliable protocol that represents the state-of-the-art communication protocol that is implemented by building upon all the experience we have seen in the real world with NDI across a massive variety of different installations
Reliable UDP, also known as RUDP, is a transport protocol that combines the advantages of UDP's low latency and simplicity with the reliability of TCP (Transmission Control Protocol). It is designed specifically for real-time multimedia applications, where maintaining the timeliness of data is crucial.
In the context of NDI, Reliable UDP is employed to ensure that video and audio streams are delivered reliably and with minimal delay. It achieves this by implementing several mechanisms:
Sequencing: Reliable UDP assigns a sequence number to each packet it sends. This allows the receiving end to detect missing or out-of-order packets and request retransmissions if necessary.
Retransmissions: If a packet is lost or arrives out of order, the receiving end can request a retransmission of the missing packet(s) using the sequence number information.
Flow control: Reliable UDP incorporates flow control mechanisms to manage the rate of data transmission. This prevents overwhelming the network or the receiving device with more data than it can handle, ensuring a smoother streaming experience.
Congestion control: RUDP also includes congestion control algorithms to prevent network congestion and avoid unnecessary packet loss. It dynamically adjusts the transmission rate based on network conditions, maintaining optimal throughput without overwhelming the network.
Multipath TCP – NDI 4
This protocol permits transport across multiple NICs and all network paths, it is intended to use hardware-accelerated network adapters with adaptive bandwidth sharing across NICs.
Multipath is a transmission protocol that offers advantages such as maximizing throughput, optimizing resource usage, and enhancing network redundancy. It can seamlessly integrate multiple network pathways, including wireless and mobile networks. It is especially efficient when used with NDI equipment that utilizes multiple Gigabit connections to exchange a large number of NDI streams.
However, in scenarios where 10Gbit interfaces are connected with 1Gbit interfaces, Multipath TCP's efficiency is compromised. This is primarily due to network switches being unable to effectively manage network congestion in such situations. As a result, the protocol may not perform optimally in these specific network configurations.
UDP with Forward Error Correction – NDI 3
This alternative protocol to is used when reliable delivery of data is not required. is typically used for applications where timeliness is of higher priority than accuracy, such as streaming media, teleconferencing, and voice-over-IP (VoIP). Forward error correction (FEC) is a method of obtaining error control in data transmission in which the source (transmitter) sends redundant data to the destination (receiver).
UDP (User Datagram Protocol) with Forward Error Correction (FEC) is a beneficial approach when the network is prone to errors or not entirely reliable. It provides a solution for error correction when data packets get lost or corrupted during transmission.
However, it's important to note that using UDP with FEC requires additional computational processing on the receiver side. The receiver needs to implement algorithms and mechanisms to manage the error correction process. This involves decoding the received data and applying error correction techniques to recover any lost or corrupted packets.
Single TCP – NDI 1
This network communications protocol enables two host systems to establish a connection, exchange data , and ensure data is delivered intact to the correct destination. is typically grouped with IP (Internet Protocol) and is collectively known as TCP/IP.
Single-TCP is supported on all NDI versions. While the other transmission modes are likely to perform better, this mode offers baseline compatibility for all NDI clients.
Last updated
Was this helpful?
