NDI sits between traditional video cabling and internet delivery, and that is exactly why it is useful in studios, control rooms, and hybrid events. This article explains what is NDI streaming, how the protocol moves video, audio, and metadata across a network, and when it makes more sense than HDMI, SDI, RTMP, or SRT. I’ll also cover the bandwidth numbers, the network conditions that matter, and the mistakes that usually show up first.
The essentials in one glance
- NDI stands for Network Device Interface, an IP-based way to move live video, audio, control, and metadata between devices.
- It is a production transport layer, not a public streaming platform. I use NDI upstream, then hand the finished programme to an encoder or streaming service.
- Full NDI / High Bandwidth gives the best quality and latency, but it wants more network headroom.
- HX3 cuts bandwidth sharply and is often the practical choice for cameras, compact setups, and constrained networks.
- Gigabit Ethernet is the baseline. Wi-Fi can work in some cases, but I would not make it the default for critical live work.
- NDI Bridge is the official route when you need to carry NDI beyond a local network.
What NDI actually is in practice
I think of NDI as a shared IP layer for live production. Instead of running separate HDMI or SDI lines from every camera to every destination, you put sources on the network and let switchers, recorders, graphics systems, and monitoring stations subscribe to them. That is why it matters in multi-camera studios, lecture capture, houses of worship, and corporate events.
The key detail is that NDI is not a codec. It is a transport standard with multiple formats, and those formats decide the codec, bandwidth, latency, and image quality. In other words, NDI is the workflow; the format you choose is what determines how heavy that workflow becomes on the network.
It also carries more than picture and sound. Tally, PTZ commands, and custom metadata can travel in the same pipeline, which makes the whole setup feel cleaner once everything is configured properly. Once you see NDI as a production transport layer rather than a delivery platform, the next question is how the data actually moves.
How the protocol behaves on a network
On a local network, discovery usually happens automatically through mDNS/Bonjour, so devices appear without much manual setup. When you need more control, NDI can also use its messaging services for manual discovery. Under the hood, newer NDI versions use a Reliable UDP approach tuned for real-time media, which gives you low latency without treating packet loss like a fatal event.
In plain English, the protocol is designed to keep timing tight, notice when packets go missing, and recover quickly enough that live video remains usable. That matters because live production is unforgiving: if the network hesitates, you see it as stutter, dropped frames, or control lag almost immediately.
Bandwidth is also not fixed in the way people sometimes expect. NDI stream load changes with resolution, frame rate, scene complexity, and the format in use, so I size a network for average load plus headroom rather than for one neat number. If one feed is being requested by three receivers on a unicast path, the traffic effectively triples, and that is where small networks usually start to feel fragile. Once you understand the transport, the real decision becomes which NDI format fits the job.
Which NDI format fits your setup
In 2026, I would focus on High Bandwidth and HX3 for new builds. HX1 is a legacy format, and I would not design a fresh system around it. The compressed family is useful, but the right choice depends on whether you are optimising for quality, latency, or network efficiency.
| Format | Typical bandwidth at 1080p60 | Latency | Best for | Main trade-off |
|---|---|---|---|---|
| High Bandwidth | About 150-165 Mbps | Sub-frame, usually under 100 ms | Studios, pro live events, switching with tight lip-sync and confidence monitoring | Higher network load |
| HX3 | Around 50 Mbps, depending on codec and scene | Up to about 150 ms | Bandwidth-limited installs, wireless cameras, lecture capture, content creation | More compression and slightly looser timing |
| HX2 / HX1 legacy | Implementation-dependent | Varying | Compatibility with older hardware | Not where I would start a new design |
All of those figures are approximate. Resolution, frame rate, scene motion, and device implementation can move the numbers around, and 4K60 pushes the bandwidth story much harder than 1080p60. The practical lesson is simple: if you want the cleanest live production experience, choose the format first and then build the network around it.
What your network needs before NDI feels reliable
A decent switch matters more than most people admit. NDI is happiest on a managed Gigabit network with enough headroom for multiple active streams, because it is designed to move production traffic across IP rather than across the public Internet. I would treat office Wi-Fi as a last resort, not a default.
- Use Gigabit Ethernet as the baseline. NDI becomes far easier to trust once the network is not the bottleneck.
- Use CAT5e or better and respect the usual roughly 100 m cable limit before signal quality starts to fall away.
- Keep discovery services available. mDNS/Bonjour helps devices appear automatically, and manual discovery relies on the NDI messaging services and their ports.
- Enable DHCP to reduce setup friction unless your environment has a very specific reason not to.
- Plan PoE budgets carefully. Small converters may draw around 15 W, cameras can need PoE+ at roughly 25-30 W, and some devices push into PoE++ territory.
- Separate NDI and Dante when they share a plant. I prefer VLAN separation rather than asking two real-time systems to compete on one flat network.
- Test Wi-Fi only when you have to. If wireless is unavoidable, Wi-Fi 6 or Wi-Fi 7 hardware and a clean RF environment give you the best chance of stable results.
There is also a simple mental rule I use: if the network is shared with normal office data, design for congestion. If the network is dedicated to production, you can be far more aggressive with source count and switcher options. That distinction leads directly to the bigger comparison most teams need to make.
Where NDI sits beside HDMI, SDI, RTMP, and SRT
The confusion around NDI comes from the word streaming. It does stream video, but not in the same job as RTMP or SRT. I usually split the workflow into three layers: local transport, contribution, and delivery.
| Technology | Best at | Where it falls short |
|---|---|---|
| NDI | Moving multiple live sources inside a production network with low latency, tally, PTZ, and metadata | Not the cleanest answer for direct public Internet delivery |
| HDMI / SDI | Simple point-to-point camera or switcher connections with predictable behaviour | Less flexible, more cabling, harder to scale across a facility |
| RTMP | Sending a finished programme to a platform or platform ingest point | Not designed for rich multi-source studio routing |
| SRT | Reliable contribution over the Internet or between sites | Better for delivery and remote feeds than for full internal production switching |
If I need to link remote sites, I do not force standard NDI onto the public Internet and hope for the best. I use NDI Bridge or switch to a contribution protocol that is built for that path. In practice, NDI works best upstream, before the final encoder or distribution step, not as the last mile to the audience. That is why the wrong setup usually fails for workflow reasons before it fails for pure technology reasons.
The mistakes that usually cause poor results
Most bad NDI experiences come from unrealistic assumptions, not from the protocol itself. When I troubleshoot a weak setup, the pattern is usually one of a few predictable mistakes.
- Using consumer Wi-Fi for a mission-critical show. It can work in a pinch, but it is rarely the right foundation.
- Ignoring how unicast multiplies traffic. One source requested by multiple receivers is not one stream anymore from the network’s point of view.
- Buying gear based on the word NDI alone. Full NDI and HX variants do not behave the same, so the label on the box is not enough.
- Mixing heavy AV protocols on one flat network. NDI and Dante can coexist, but they usually behave better when separated cleanly.
- Skipping discovery and switch configuration. If devices cannot see each other cleanly, the whole system feels unreliable even if the hardware is fine.
- Trying to make HX1 the centre of a new build. I would treat it as legacy compatibility, not as a future-proof choice.
There is a second mistake that is more strategic than technical: expecting NDI to do everything. It is brilliant for internal live production, source sharing, monitoring, and routing, but it is not automatically the best tool for audience delivery or long-haul contribution. Once that boundary is clear, the decision gets much easier.
The practical decision I would make in 2026
If the goal is a multi-source live production workflow inside one site, I would choose NDI first and build the network properly around it. If the goal is only to send one finished feed to a public platform, I would keep NDI upstream and hand the output to RTMP or SRT. If the link has to cross a WAN or an unpredictable Internet path, I would reach for NDI Bridge or a contribution protocol rather than trying to make standard NDI solve a problem it was not designed to solve.
- Choose NDI when you need several cameras, graphics machines, and monitors to talk on one live production network.
- Choose High Bandwidth when image quality and low latency matter more than reducing traffic.
- Choose HX3 when bandwidth is tighter or the camera has to live in a more constrained setup.
- Choose RTMP or SRT for delivery and remote contribution.
- Choose NDI Bridge when the workflow has to extend beyond the local network.
My rule of thumb is straightforward: use NDI for production, then use the right delivery protocol for distribution. That keeps the system easier to troubleshoot, easier to scale, and much less dependent on luck when the show goes live.
