The SDI vs NDI decision is less about which standard sounds newer and more about which transport fits the risk profile of the show. In live video, that choice affects latency, cabling, scaling, troubleshooting and how much of the workflow lives in hardware versus on the network. I would read this as a practical comparison for streamers, studios and venue teams that need a system to work reliably, not just look elegant on a spec sheet.
The practical choice is between deterministic transport and network flexibility
- SDI is still the safer default for the main programme path when latency, stability and simple troubleshooting matter most.
- NDI is better when cameras, graphics, control and monitoring need to move over IP with less cabling.
- A typical NDI 1080p60 stream can reach about 150 Mbps, so bandwidth planning matters quickly.
- 12G-SDI handles SD, HD and Ultra HD up to 2160p60 on a single multi-rate link.
- For most live streaming rigs, a hybrid design gives the best balance of reliability and flexibility.
What SDI and NDI actually do differently
SDI, or Serial Digital Interface, is a baseband video path. In plain terms, it moves uncompressed digital video over coax or fibre as a direct signal, usually point to point or through an SDI router. NDI, or Network Device Interface, is IP-based video: the signal is encoded, sent over Ethernet and discovered through the network, which lets devices exchange video, audio and metadata in a much more software-friendly way.
The difference matters because they behave differently under load. SDI is predictable by design. NDI is powerful, but it is also a networked system, so bandwidth, switching and configuration all matter. NDI's own guidance says it is not deterministic, which means I plan it around average utilisation and headroom rather than assuming every packet will behave like a baseband feed.
| Criterion | SDI | NDI |
|---|---|---|
| Transport | Baseband video over coax or fibre | Video over IP on Ethernet |
| Latency behaviour | Very low and predictable | Low, but dependent on network and codec choice |
| Bandwidth model | Fixed per signal format | Variable, based on stream type and resolution |
| Routing | Point to point or through an SDI router | Discovered and routed over the network |
| Extra data | Embedded audio and ancillary data | Audio, metadata, tally, PTZ and control data |
| Best fit | Main programme paths, fixed installs, broadcast trucks | Software-driven, distributed or fast-changing workflows |
That transport model explains most of the real tradeoff. Once you see the difference, the next question is not which one is more modern, but where each one starts to show its limits.
Why SDI still wins when the main feed cannot fail
For mission-critical live paths, I still trust SDI first. It is boring in the right way: the signal path is direct, the behaviour is easy to reason about and the failure modes are usually physical rather than abstract. If a feed disappears, you trace the cable or the router path. You are not debugging a switch configuration while talent is waiting on a downstage monitor.
SDI also scales farther than people sometimes assume. Blackmagic's current 12G-SDI gear lists multi-rate support from 270Mb through 12G, with automatic detection of SD, HD, 2K, Ultra HD and 4K formats. That means a single 12G link can handle workflows up to 2160p60, which is still a very practical ceiling for many live productions. With fibre conversion, SDI can also travel a long way when the route demands it.
- It is easy to troubleshoot because the path is direct and visible.
- It is stable under pressure because other network traffic is not competing with it.
- It fits established broadcast gear such as routers, replay systems and monitors.
- It remains useful for long-term installs where the camera positions are fixed and the workflow is unlikely to change every month.
In a small studio, gallery or event truck, SDI often wins because simplicity has real value. The moment the workflow starts moving across rooms, devices or software layers, though, the argument shifts and NDI becomes much more interesting.
Where NDI changes the economics of a live setup
NDI is most compelling when video needs to behave like data. It lets cameras, graphics engines, control surfaces and monitoring devices live on the same network fabric, and that makes routing much faster to reconfigure. NDI's ecosystem also carries useful extras in-stream, including alpha, tally, PTZ commands and custom XML metadata, which is one reason it fits live graphics and remote control so well.
The bandwidth story is the part that needs discipline. NDI's own documentation says Gigabit Ethernet is the baseline for production workflows, and that a typical 1080p60 stream can reach up to 150 Mbps. That is efficient, but it is not free. A few feeds are comfortable; a lot of feeds add up fast. The official docs also note that NDI is not deterministic, so I would never treat a busy general-purpose office network as if it were a production backbone.
For current NDI formats, the useful split is simple. High Bandwidth uses SpeedHQ and is the choice I make when image quality and latency matter more than network frugality. HX formats use H.264 or H.265 and are better when bandwidth is tight or the use case is more forgiving.| NDI format | Typical bandwidth | Latency | Best use |
|---|---|---|---|
| High Bandwidth | About 165 Mbps at 1080p60 and about 312 Mbps at 2160p60 | Under 100 ms | Broadcast studios, pro live events, higher-end installs |
| HX2 and HX3 | Roughly 11 to 16 Mbps at 1080p60 for H.265 or H.264, with higher figures at 2160p60 | Up to about 150 ms depending on format | Lecture capture, corporate streams, tighter bandwidth setups |
NDI can also work beyond the local LAN through bridge and cloud options, which makes it attractive for contribution workflows and distributed teams. I still treat that as a specialised extension rather than the default path for the main programme feed. The real strength of NDI is flexibility, and the real price of that flexibility is network discipline.
How I choose between them on a real project
When I spec a live workflow, I do not start by asking which standard is better in the abstract. I ask how the show changes, who has to troubleshoot it, and what would actually hurt if it failed. For a UK venue, studio or education space, that usually means balancing a stable core with a more flexible edge.
| Situation | I would choose | Why |
|---|---|---|
| Fixed cameras, one control room, very little change | SDI | It is simple, predictable and easy to support |
| PTZ cameras, graphics machines, multiple rooms, frequent reconfiguration | NDI | Routing is faster and cabling is lighter |
| Main programme plus remote guests, overlays and monitoring | Hybrid | Keep the critical path stable and use IP where it saves time |
| Long runs across a building with limited cable access | Hybrid or fibre SDI | Distance and building constraints often decide the route |
| Small streaming rig with a couple of sources | SDI if the layout is fixed, NDI if the layout moves | The simplest option is usually the one that breaks least |
My rule of thumb is blunt: if the main feed must never become a network debugging exercise, keep that feed on SDI. If a source exists mainly to be routed, shared, duplicated or controlled in software, NDI starts to earn its place. The architecture becomes clearer once you separate programme risk from workflow convenience.
The tradeoffs that usually decide the outcome
The hidden costs are where most bad decisions happen. I see teams overestimate the savings of all-IP workflows and underestimate the engineering work required to make them robust. I also see the opposite mistake, where people keep everything on SDI even when the production would be simpler, cheaper to reconfigure and easier to scale with NDI.
- Bandwidth is cumulative. One 1080p60 NDI stream can reach about 150 Mbps, so six or eight sources can consume a large slice of a Gigabit network before overhead.
- Not all NDI flavours behave the same. High Bandwidth is the safer choice when quality and latency matter; HX is for tighter bandwidth budgets.
- Shared networks are dangerous. If live video sits beside backups, file transfers and general office traffic, you are asking for jitter.
- Wi-Fi is not a serious default for critical live paths. It can be useful for special cases, but I would not build a show around it.
- Every conversion point adds complexity. SDI-to-NDI bridges, decode boxes and virtual inputs all need power, configuration and testing.
- SDI has costs too. Cable bulk, patching, router ports and physical rerouting all add up as a production grows.
Once those tradeoffs are visible, the answer stops looking ideological. You begin to see that the job is not to pick a winner, but to place each transport where it does the least harm and the most good.
The hybrid setup I trust for most live streams
If I were building a new live streaming system from scratch, I would usually keep the main programme chain on SDI and use NDI where flexibility pays back quickly. That means cameras into the switcher on SDI, then NDI for graphics, auxiliary sources, remote contribution, control surfaces and software distribution. It is a conservative core with a modern edge, and that mix tends to survive real-world change much better than a pure one-standard approach.That hybrid model also scales better over time. You can add NDI sources without ripping out the stable SDI backbone, and you can keep the most sensitive parts of the show away from network contention. For most live teams, that is the sweet spot: predictable where it matters, flexible where it helps.
The practical answer is rarely about loyalty to one standard. It is about building a live-video path that stays calm under pressure, gives you room to grow and does not create extra work every time the production changes.
