Tutorials Streaming

What NDI Is and How It Is Actually Used

Intermediate · ~25 min

Overview

NDI is a way of sending video, audio, and metadata between devices over an ordinary computer network instead of over dedicated video cabling. Developed by NewTek and now maintained by Vizrt, it is royalty-free, widely implemented, and has become the default way small and mid-sized productions move pictures around a building. The appeal is simple: any machine on the network can offer a source, and any other machine can see it without anyone running a cable. This guide covers how it works, what the variants actually differ on, where it genuinely belongs, and, just as usefully, where it does not.

What You Need

A wired gigabit network. This is the single hard requirement
A managed switch if you plan to run more than a handful of streams
Software or hardware that speaks NDI at both ends
The free NDI Tools package, which is the fastest way to test anything
Somewhere to put the traffic that is not your general office network
A realistic count of how many simultaneous streams you actually need

Steps

Understand what problem it replaces

Traditional video plumbing is point-to-point: one SDI cable carries one signal in one direction, and changing what goes where means either re-patching or buying a routing matrix. NDI inverts that. Sources announce themselves on the network, any receiver can list what is available and subscribe to it, and adding a source is a software change rather than a cabling job.

Know how devices find each other

Discovery is automatic on a local network, sources advertise themselves and receivers present them as a list of names. This is why NDI feels effortless on a flat network and why it appears broken across subnets or VLANs, where that automatic discovery does not cross the boundary. For those cases you point receivers at a discovery server or specify sources manually.

Pick the right variant for the job

The full-bandwidth flavour is lightly compressed, effectively transparent for production purposes, and has very low latency, but each stream consumes a substantial share of a gigabit link. The HX variants use much heavier long-GOP compression, which drops bandwidth by roughly an order of magnitude at the cost of added latency and generational quality loss. Cameras, phones, and anything crossing a constrained link typically use HX. Machine-to-machine within a rack uses full bandwidth.

Budget bandwidth before you build

Count the streams that will actually be in flight at once, remembering that a source consumes bandwidth per receiver unless you are using multicast. A gigabit link carries a useful handful of full-bandwidth 1080p streams and far fewer at higher resolutions or frame rates. Work out that number first. It determines whether you need 2.5-gigabit or 10-gigabit uplinks, and it is the single most common thing people get wrong.

Give it a network of its own

NDI is sensitive to latency and jitter rather than just raw throughput, so it shares badly with backups, file copies, and general office traffic. A separate physical network or a dedicated VLAN on a managed switch is the standard arrangement. If you plan to use multicast, enable IGMP snooping and a querier, or the traffic will be flooded to every port and take the network down with it.

Test with the free tools before committing

The NDI Tools package includes a screen-capture source, a monitor for viewing any source on the network, test patterns, and a virtual input that presents an NDI source to software expecting a webcam. Between them you can prove out discovery, measure real-world latency, and load-test your switch before anyone spends money.

Pro Tips

Wire everything. Full-bandwidth NDI over WiFi is unreliable at best. If a device must be wireless, use an HX variant and expect added latency.
Name your sources deliberately. On a busy network the receiver list becomes unusable when everything is called "Desktop" or "OBS".
Each additional receiver of a unicast source costs another copy of that bandwidth. Multicast changes that arithmetic, and adds its own switch requirements.
Do not chain compression. Sending an HX stream into a system that re-encodes it for another HX hop visibly degrades the picture.
Treat NDI as unencrypted on the local network. Anything sensitive belongs on an isolated segment rather than a shared corporate LAN.

Knowledge Base

What You'll Learn

Below: how the compression and latency trade-off actually works, what each variant is for, how audio is carried, the workflows where NDI has become standard, an honest account of its place in post production, and how it compares with the alternatives.

The trade-off that defines every NDI decision

Everything about deploying NDI reduces to a three-way trade between bandwidth, latency, and quality. You do not get to optimise all three, and the variants exist precisely to let you choose which one to sacrifice.

Full-bandwidth NDI compresses each frame independently, lightly. Because there is no dependency between frames, a decoder can start on any frame and the encode/decode delay is very short, commonly around a frame or less end to end. The cost is bitrate: a single 1080p60 stream runs on the order of a hundred-plus megabits per second, which is a meaningful fraction of a gigabit link before you have added a second source.

HX variants use long-GOP encoding, where most frames are described as differences from other frames. That is dramatically more efficient, bandwidth drops by roughly an order of magnitude, but the encoder must buffer, the decoder must wait for a reference frame, and latency rises accordingly. It also means quality degrades if the stream is re-encoded further downstream.

Exact figures shift between NDI versions, resolutions, frame rates, and even content complexity, so treat any specific number you read, including the ones above, as an order of magnitude and check current vendor documentation when you are sizing a real system.

The variants, and what each is actually for

Variant	Compression	Relative bandwidth	Typical use
NDI (full / High Bandwidth)	Light, intra-frame	High	Machine-to-machine within a facility: switcher, graphics, playback, capture
NDI\|HX (and later HX generations)	Long-GOP H.264 / H.265	Roughly a tenth	PTZ cameras, phones and tablets, encoders, anything crossing a constrained link
NDI Bridge	Depends on source	Depends on source	Joining NDI environments in different buildings over the public internet
Audio-only sources	Uncompressed float	Low	Distributing mixes, comms, and reference audio without a video payload

The practical rule: use full bandwidth where the devices sit on the same well-provisioned switch and latency matters, and HX everywhere the link is the constraint. Mixing both in one production is normal and expected rather than a compromise.

How audio is carried, and why that matters

NDI is not a video protocol with audio bolted on. It carries multi-channel audio as floating-point samples alongside the video, and it will happily carry audio with no video at all.

Two consequences are worth knowing. First, audio arrives embedded and in sync with its video by default, which removes an entire category of problem that exists when picture and sound travel separately and have to be re-married downstream. If you have fought sync drift between audio and video in a multi-machine setup, this is the appeal.

Second, audio-only NDI sources are genuinely useful and widely underused. A mix, a clean feed, a talkback channel, or a reference track can be distributed to any machine on the network with no hardware at all. For a corporate event or a multi-room production, that replaces a surprising amount of analogue cabling.

The caveat is that floating-point multi-channel audio is not free of bandwidth, and that the HX variants apply lossy audio compression alongside the video. For anything where the audio is the deliverable rather than a monitor feed, prefer full bandwidth or a dedicated audio transport.

Where NDI has genuinely become standard

Live switching and streaming. The dominant use. Software switchers and streaming applications almost all speak NDI, so a graphics machine, a playback machine, and a capture machine can all feed one switcher with no capture cards. If you already run OBS, adding an NDI source is usually a plugin and a dropdown.

Multi-camera production at modest scale. PTZ cameras with NDI built in are now common, and they need one cable that carries video, audio, control, and often power. For multi-camera sports coverage in a fixed venue that is a substantial simplification over running SDI to every position.

Presenter and screen feeds. Capturing a laptop as a source without a scan converter or an HDMI run is one of NDI's most-used features, and it is what makes corporate town halls and hybrid events practical with a small crew.

Esports and game capture. Gameplay machines producing an NDI output remove the capture-card layer entirely, which matters when there are many stations. See esports production for how the observer and overlay layers fit around it.

Distributed and remote contribution. Bridging NDI between sites lets a remote presenter or a second gallery appear as an ordinary source, though anything crossing the public internet inherits that network's reliability.

Its place in post production. The honest version

NDI is far less established in post than in live production, and it is worth being clear about why rather than implying it is a finishing tool.

Where it does earn a place: sending a timeline output to a monitor or a machine in another room. Feeding a review screen for clients or producers without a video router. Getting a picture out of an edit suite and into a streaming or conferencing tool for a remote review session. And multi-machine setups where one workstation renders and another displays.

Where it does not belong: as a colour-critical reference path. Grading and finishing depend on a deterministic, uncompressed, correctly-managed signal to a calibrated display. NDI is compressed, travels over a network that can introduce jitter, and passes through software colour handling that varies by implementation. Judging a grade on an NDI feed is judging the transport as much as the image, which is the same argument made in our guide to monitor setup for grading, and it applies with more force here.

Frame-accurate review is the other limitation. NDI is a live stream, not a timeline. It has no concept of scrubbing, and round-trip latency makes it poor for anything requiring precise frame-by-frame discussion. Dedicated review-and-approval platforms exist for that reason.

The reasonable summary: excellent for getting a picture from one place to another in a facility, unsuitable as the last link before a critical judgement.

The network is the system

Most NDI problems are network problems wearing a video costume, and they present as dropped frames, stuttering, or sources appearing and vanishing from the list.

Bandwidth per receiver. With unicast, every additional receiver of a source means another full copy of that stream leaving the sender. Three machines watching one full-bandwidth feed is three times the traffic. Multicast sends one copy that the switch replicates: which is why it exists, and why it demands a managed switch with IGMP snooping and a querier configured. Enabling multicast on an unmanaged switch floods every port and is a reliable way to take down a network.

Jitter over throughput. A link with spare capacity but inconsistent delivery produces worse results than a busier but steadier one. This is why NDI shares poorly with bulk file transfer and why a dedicated VLAN is standard practice rather than caution.

Discovery boundaries. Automatic discovery relies on local network multicast, which does not cross subnets. Sources vanishing when a device moves to another VLAN is expected behaviour, not a fault, and is solved with a discovery server or manual source entry.

Security. Traffic on a local network is not encrypted by default. Treat any NDI segment as visible to anyone on it, and isolate accordingly, particularly for confidential corporate content, which is exactly the material most likely to be flowing through a town-hall setup.

How it compares with the alternatives

Transport	Compression	Typical scope	Best suited to
SDI	None	Point-to-point cable	Deterministic, colour-critical, high-end live and finishing
NDI	Light to heavy, selectable	Local network	Facility and small-to-mid production, software-heavy workflows
SMPTE ST 2110	None (uncompressed essences)	Engineered IP network	Broadcast infrastructure with precise timing and dedicated engineering
SRT	Depends on encoder	Public internet	Contribution and remote links over unreliable networks

These are complements rather than competitors, and large facilities run several. The distinction that matters when choosing: SDI and ST 2110 are engineering-grade and expensive in cabling or in network design. NDI is pragmatic and cheap and trades a little quality and determinism for enormous flexibility. SRT solves a different problem entirely, which is getting a signal across a network you do not control. Our guide to broadcast ingest covers where the engineered end of that spectrum sits.

Where This Fits

This guide covers one specific part of livestreaming. The wider picture (scene and source structure, encoding, bitrate, and audio routing for a reliable stream) is in OBS Studio for Beginners, which frames the discipline as a whole and links out to the detailed guides underneath it, including this one. If you are starting from scratch rather than solving a specific problem, read that first and come back here.

FAQ

Q: What does NDI actually stand for?
A: Network Device Interface. It is a specification for carrying video, audio, and metadata between devices over standard IP networks, originally developed by NewTek and now maintained by Vizrt. It is royalty-free to implement, which is a large part of why support became so widespread.

Q: What is the difference between NDI and NDI|HX?
A: Compression, and therefore bandwidth and latency. Full NDI compresses each frame independently and lightly, very low latency, visually transparent, high bitrate. HX uses long-GOP H.264 or H.265, cutting bandwidth by roughly an order of magnitude at the cost of higher latency and more quality loss if re-encoded. Cameras and constrained links use HX. Machine-to-machine usually uses full bandwidth.

Q: Can NDI run over WiFi?
A: HX variants sometimes can, at higher latency and with a real risk of dropouts. Full-bandwidth NDI over WiFi is not reliable and should not be planned for. Wire anything that matters. This is the most common cause of NDI problems people attribute to the software.

Q: How many NDI streams fit on a gigabit network?
A: For full bandwidth 1080p, a useful handful rather than dozens, and fewer again at higher resolutions or frame rates. Remember that unicast sends a separate copy per receiver, so three machines watching one source triples the traffic. Count your simultaneous streams and receivers before choosing switch and uplink speeds.

Q: Is NDI good enough for colour grading?
A: No. It is compressed, subject to network jitter, and passes through software colour handling that varies between implementations, so you would be judging the transport as much as the image. Use it to get a picture to a room. Use a proper monitoring chain to a calibrated display for any critical colour decision.

Q: Do I need special hardware to use NDI?
A: No. The free NDI Tools package turns an ordinary computer into a source and a receiver, and most switching and streaming software supports it directly. Dedicated NDI cameras, converters, and encoders exist and are convenient, but nothing stops you proving the whole workflow with machines you already own.

Q: Is NDI traffic encrypted?
A: Not by default on a local network. Treat an NDI segment as readable by anyone with access to it, and put confidential material on an isolated network rather than a shared corporate LAN. This matters most for exactly the internal-communications content people most often route through it.