NDI Network Design: Bandwidth, Switches, and Segmentation

What NDI network design has to get right

Get the plan wrong and you get dropped frames. Stutter. Discovery that half-works. NDI is video over standard IP: it rides the same Ethernet as the rest of your network, the same switches, the same cabling. Which is exactly why NDI projects succeed or fail on the network rather than on the cameras. Designing one is not mysterious, but it is unforgiving, because a few uncompressed-ish video streams put more sustained load on a link than an entire office floor.

Five questions, answered in order, make a workable NDI plan. How much bandwidth does one stream use? How many streams cross each link? Are the switches fast enough where it counts? Is multicast contained? Is NDI kept clear of the traffic it would trample, meaning Dante audio and show control? Everything below walks those in turn. NDI shows up most often on a multicamera livestream signal flow, so that is the mental picture to hold: several camera feeds converging on a switcher or media server, all on the wire at once.

Full NDI vs NDI HX: the bandwidth fork

Per-stream bandwidth is the single biggest number in your plan, and it splits along the NDI variant. Full NDI (often labeled High Bandwidth) prioritizes quality and low latency with light compression. It is the heavy one. NDI HX is more aggressively compressed (H.264 / H.265-class codecs) for dramatically lower bandwidth, which is why PTZ cameras and links over constrained networks tend to speak HX. The two can differ by roughly an order of magnitude; a rig that mixes them carries two separate budgets.

Actual bitrates move with resolution, with frame rate, with content, with NDI version. Exact figures therefore belong to NDI's documentation and its own bandwidth tools; a blog is the wrong place to get them. As a rough planning anchor only: Full NDI streams commonly run in the ~100+ Mbps range per 1080p stream depending on settings, and higher for 4K. NDI HX lands well below that. Use those as placeholders to shape the design, then replace them with measured numbers before you spend money on switches.

Budget bandwidth per link, not per building

Total NDI traffic in the building is the wrong number. What matters is how much crosses each individual link. The link that bites? Almost always the uplink between two switches. A stage switch feeding eight camera feeds up one trunk to a control-room switch has to carry all eight at once on that trunk, even though each edge port carries only one. Size every link to the streams that actually traverse it.

Placeholder per stream: assume ~125 Mbps for one 1080p Full NDI stream. This is a placeholder for sizing only, confirm the real value in NDI's documentation and with NDI's bandwidth tools.
Streams crossing the uplink: count only flows that traverse this link. Say 8 camera feeds live on a stage switch and all 8 are switched or recorded on the far side of one uplink.
Raw media load: 8 streams x 125 Mbps = 1,000 Mbps = 1.0 Gbps.
Headroom: never fill a media link to 100%. At a 65% utilization target, 1.0 Gbps / 0.65 is about 1.5 Gbps of uplink wanted.
Verdict: a single 1 Gbps uplink is already full before headroom, so 8 Full NDI streams on one link points to a 10 Gbps uplink (or link aggregation), not a gigabit trunk.

Switch requirements: gigabit to the edge, 10G where it stacks up

NDI runs on ordinary managed switches. Two throughput rules decide whether it runs well. First: gigabit to every endpoint is the practical baseline, and 100 Mbps ports do not belong anywhere near Full NDI. Second: the moment many streams aggregate onto one path, that path needs to grow, which is where 10G uplinks (or aggregated gigabit links) earn their cost. The edge stays gigabit. The spine goes fast.

• Gigabit access ports: one or a few streams fit comfortably on a gigabit link, which is why NDI feels easy on a small setup and bites at scale; the edge was never the problem.
• Fast uplinks and backbone. Sum the streams crossing each trunk (the calc above). Provision the uplink for that plus headroom. Non-blocking switches matter here: a switch that cannot forward all ports at full rate simultaneously will quietly drop your streams under load.
• Buffers and features: real-time video is unforgiving of congestion, and vendor AV-over-IP switch guides call out what matters for NDI here: buffer sizing, IGMP behavior, QoS defaults. Use them rather than guessing from the spec sheet.

Multicast, IGMP, and discovery

NDI can send a stream as unicast: one copy per receiver. In setups that enable it, NDI can also send multicast, one flow that many receivers subscribe to. Multicast saves bandwidth when a source has several viewers. The catch breaks naive networks: a switch with no multicast management floods every multicast flow to every port in the broadcast domain. With Full NDI video, that flood can saturate links that had nothing to do with the stream.

Every AV-over-IP media network uses the same recipe, and the fix here is no different: IGMP snooping so the switch forwards each multicast group only to ports that asked for it, plus a working IGMP querier on the media network to keep those subscriptions alive. Which NDI variant defaults to unicast versus multicast, and how you enable each, is a documentation question. Confirm it for your version rather than assuming. The snooping and querier mechanics live in VLAN planning for AV systems.

Discovery is the other half. NDI sources announce themselves so receivers can find them. By default that discovery is local to a subnet (mDNS-style). The moment senders and receivers sit on different subnets or VLANs, local discovery stops crossing the boundary; you then point devices at an NDI Discovery Server (or the vendor's current equivalent) so they register centrally. Plan discovery deliberately whenever your segmentation splits sources from the systems that consume them.

Keep NDI off the Dante and control lanes

NDI's large, bursty video flows are the loud neighbor of an AV network. Share one flat network with Dante audio and show control and NDI will, sooner or later, starve the traffic that least tolerates it. Audio wants a quiet, deterministic path. Control needs its packets to land on time. Segmentation is the standard answer: give NDI its own media VLAN so its load and its multicast stay contained.

Segmentation also forces the discovery and routing decisions above into the open. That is a feature: you decide on purpose how NDI crosses between subnets instead of discovering at show time that it does not. Assign every NDI interface an address inside its VLAN's subnet in your IP schedule. Record which switch port carries which VLAN so the built network matches the plan.

In WireFlow, the NDI VLAN lives on the same diagram as the signal flow. So does each source's IP, and so do the switch ports it lands on, with the runs documented port to port. That keeps the bandwidth plan you sized here in one source of truth the crew can actually follow, along with the segmentation and the discovery scheme, instead of a diagram and a spreadsheet and a switch config drifting apart. The rest of the AV networking guides build on the same map.

NDI network planning at a glance

An NDI plan is a short list of figures to confirm rather than memorize, so fold this into your preproduction workflow and fill the right-hand column from current NDI sources before you commit hardware:

Common NDI network mistakes

• Sizing per switch instead of per link: bandwidth burns on the uplink between switches, so count the streams crossing each link rather than the total everywhere.
• Treating Full NDI and NDI HX as one number. They differ enormously. A rig that mixes PTZ HX cameras with Full NDI feeds has two separate budgets to add up.
• Leaving multicast unmanaged: optional multicast with no IGMP snooping floods every port, so either keep NDI within unicast capacity or run snooping plus a querier on the media network.
• One flat network for everything. NDI's large flows drown quieter, latency-sensitive Dante audio and show control. Segment before it bites, not after.
• Trusting the link light: a gigabit link negotiates fine and still saturates under a few Full NDI streams, so measure under real load rather than assuming green means good.
• Hardcoding a bitrate from a page like this one. Bitrates shift across NDI versions and settings. Confirm the real figure against current NDI tools before it drives switch spend.

Frequently asked questions

How much bandwidth does one NDI stream use?

It depends on the variant and settings. Treat any single number as a planning placeholder rather than a spec. Full NDI is heavy: commonly cited in the ~100+ Mbps range for a 1080p stream as a rough figure. NDI HX is a fraction of that. Confirm the current value in NDI's documentation and with NDI's bandwidth tools before sizing switches.

What is the difference between Full NDI and NDI HX?

Full NDI (High Bandwidth) favors quality and low latency with light compression, which costs more bandwidth. NDI HX is more heavily compressed (H.264 / H.265-class) for far lower bandwidth, which is why PTZ cameras and constrained links use it. Exact bitrates and codec details vary by version, so read them from NDI's docs rather than assuming.

Do I need 10 gigabit switches for NDI?

Not always. Gigabit to each endpoint is the usual baseline, and a few streams fit on a gigabit link. The 10G question is about aggregation: once many Full NDI streams cross one uplink, a single gigabit trunk saturates. Size uplinks from a per-link stream count rather than from the endpoint port speed.

Does NDI need its own VLAN?

Not strictly, but a shared flat network is where NDI's large flows disturb Dante audio and control. Putting NDI on its own media VLAN, with IGMP snooping and a querier if you use multicast, is common practice. See VLAN planning for AV systems for the segmentation and multicast mechanics.

Document your AV network in WireFlow

VLANs, IPs, PoE, and switch ports live on the same diagram as your signal flow, one source of truth for the whole system.

Start a free network plan · See the sample project