NDI, short for Network Device Interface, is a royalty-free video-over-IP protocol that carries live video, audio, metadata and control signals between cameras, switchers, graphics systems and software on an ordinary Ethernet network. In streaming and broadcasting, it replaces or supplements dedicated video cabling with the same network that already connects computers.
NDI is designed for low-latency production inside a facility, not for delivery to viewers. A source announces itself on the network, any receiver can discover and subscribe to it, and one source can feed many receivers at once, which turns a local network into a flexible virtual routing matrix.
How NDI moves video across a network
An NDI sender compresses each frame with an intra-frame codec, packages it with audio and metadata, and transmits it over TCP, UDP or multicast transport. Because every frame is coded independently, a receiver can join a stream at any moment and the encoding adds only about one frame of latency, typically well under 100 milliseconds end to end on a healthy network.
Automatic discovery is the second core mechanism. On a single subnet, sources advertise themselves through multicast DNS, so they appear in receiver menus without manual addressing. Larger installations use a discovery server, a central registry that replaces multicast announcements and allows NDI to work across routed subnets and VLANs.
NDI is bidirectional: alongside the video, a receiver can send tally information back to the source, and compatible PTZ cameras accept pan, tilt and zoom control through the same connection. A single network cable can therefore carry video, audio, tally, control and, with Power over Ethernet, power.
Audio travels as uncompressed multichannel floating-point samples embedded in the stream, and metadata frames can carry XML data such as camera settings or graphics triggers. NDI support is distributed as a software development kit, which is why the protocol appears in cameras, converters, switchers and desktop applications from many different vendors.
NDI variants and bandwidth requirements
NDI exists in several encoding variants that trade image quality against bandwidth. The choice determines how many streams a single network link can carry and how much processing the sender and receiver need.
| Variant | Compression approach | Approximate bandwidth | Typical role |
|---|---|---|---|
| Full-bandwidth NDI | Proprietary intra-frame codec, visually lossless | Around 125-150 Mbit/s | Main camera and switcher feeds |
| NDI HX | Long-GOP H.264 or HEVC | Roughly 8-20 Mbit/s | PTZ cameras, wireless and constrained links |
| NDI HX2 and HX3 | Improved long-GOP encoding with lower latency | Roughly 10-40 Mbit/s | Modern PTZ cameras and encoders |
| Proxy streams | Low-resolution preview alongside the main feed | A few Mbit/s | Multiviewers and monitoring |
Bandwidth scales roughly with resolution and frame rate, so a 2160p60 full-bandwidth stream needs several times the figure for 1080p. In practice, Gigabit Ethernet comfortably carries a handful of full-bandwidth HD streams, while larger systems or 4K workflows call for 10 Gigabit links to switchers and servers.
NDI compared with other video transports
NDI occupies the space between baseband cabling inside a facility and contribution protocols that cross the internet. It is often confused with both, but each technology solves a different problem.
| Technology | Medium | Typical latency | Primary use |
|---|---|---|---|
| NDI | Standard Ethernet LAN | About one frame | Flexible production inside a building |
| SDI | Dedicated coaxial cable | Practically none | Fixed, deterministic studio links |
| SMPTE ST 2110 | Managed IP network with PTP timing | Very low | Uncompressed broadcast infrastructure |
| SRT | Public internet | Configurable, often 120 ms to several seconds | Secure contribution between sites |
| RTMP | Public internet | Several seconds | Ingest to streaming platforms |
Compared with SDI, NDI gains routing flexibility and cable economy but loses deterministic timing, because it shares the network with other traffic. Compared with SMPTE ST 2110, it is far lighter on bandwidth and runs on unmanaged switches, at the cost of compression and less precise synchronization. To leave the building, NDI streams are usually converted to SRT or RTMP.
Designing a reliable NDI network
Most NDI problems are network design problems, not protocol faults. Full-bandwidth video creates sustained, high-volume traffic that office networks are rarely built to carry, so production traffic benefits from its own switches or a dedicated VLAN.
The following decisions have the greatest effect on stability and are worth settling before a production goes live.
| Decision | Recommended choice | Reason |
|---|---|---|
| Switch type | Managed gigabit or faster switch | Sufficient backplane capacity and traffic control |
| Connections | Wired links for full-bandwidth sources | Wi-Fi adds jitter and dropped frames |
| Multicast traffic | Enable IGMP snooping when multicast is used | Prevents video flooding every port |
| Discovery across subnets | Deploy a discovery server | mDNS does not cross routers |
| Uplinks between switches | 10 Gbit/s or link aggregation | Avoids congestion where streams converge |
Synchronization deserves attention as well. NDI receivers align streams to their own clocks, so sources from different devices can drift slightly; switchers handle this by frame synchronizing inputs, which can occasionally repeat or drop a frame.
Limitations and common mistakes
- Mixing NDI HX and full-bandwidth NDI without planning causes uneven latency between cameras, which shows as lip-sync offsets after switching.
- Running production traffic on a busy shared network leads to stutter whenever large file transfers or backups start.
- Assuming NDI is suitable for internet delivery is a misconception; it is a local production protocol, and remote access requires bridging tools or conversion to a contribution protocol.
- Underestimating CPU and GPU load on software receivers, since decoding many full-bandwidth streams is demanding on general-purpose computers.
Despite these limits, NDI has become the default interconnect for software-based production, because virtually every streaming and switching application can send and receive it without additional hardware.
Put simply
NDI lets video equipment share live pictures over a normal computer network. Instead of running a special video cable from every camera to the mixing desk, each device plugs into a network switch. Any computer or switcher on that network can then see every camera.
Think of it as a local radio station for video. Each camera broadcasts on the network, and any receiver can tune in. It works best inside one building, and it needs a solid wired network to stay smooth.
In practice
A university streams its weekly lecture series with three PTZ cameras, a slide computer and a software switcher. Each camera connects with a single Ethernet cable that carries video, control and Power over Ethernet to a managed gigabit switch on a dedicated VLAN. The cameras send NDI HX2 at about 20 Mbit/s, and the slide computer sends full-bandwidth NDI.
The operator controls the camera angles from the switcher, which also receives tally signals back to the cameras. The program output leaves the building as an SRT stream to the streaming platform. Moving a camera to a different room now requires only a network port, not a new cable run, and the setup time for each event dropped from hours to minutes.