NDI on a show network: what the switch needs from you

NDI has a reputation for being heavy on a network. It is not, particularly. What is heavy is an unmanaged switch, a venue Wi-Fi bridged into the same VLAN, and multicast enabled without anybody configuring the switch for it.

Get the network right and NDI is boring, which is the highest compliment available in live production.

The actual numbers

Full-bandwidth NDI is roughly proportional to pixels per second. Useful figures to carry:

Treat these as planning figures rather than guarantees — actual rate varies with content, since the codec is doing real compression. Busy, noisy, high-detail pictures cost more than a static graphic.

The arithmetic that matters: a gigabit link carries about six 1080p60 full-bandwidth streams before it is in trouble, and you should plan on five. Not nine, which is what 130 into 1000 suggests — headroom is not optional on a link carrying live video, because a saturated link does not degrade gracefully. It drops frames on every stream at once.

Count the links, not the streams

The most common capacity mistake is counting total streams rather than what crosses each individual link.

Four cameras and two playback machines sending to one receiving machine is six streams. If all seven devices are on one gigabit switch, the switch fabric handles it comfortably, but the receiver’s single gigabit port has to take all six — 780 Mbps into a 1000 Mbps port, before any other traffic. That is over the line.

The fix is per-link, not global:

• 10 gigabit on the machines that aggregate streams. A receiver taking many sources, or a sender publishing many outputs, is where the money goes. Everything else can stay at gigabit.
• Link aggregation helps only if the traffic hashes across the links, which per-stream video often does not. Do not rely on it to fix an over-subscribed receiver.
• Watch the uplinks. Two switches with a single gigabit link between them and video crossing that link is the classic bottleneck. If video crosses a switch boundary, that link needs to be 10G.

Unicast, multicast, and why multicast usually is not the answer

By default NDI uses unicast: a separate stream per receiver. Three receivers of one source means the sender transmits it three times.

Multicast sends one copy that many receivers can subscribe to, which sounds like the obvious fix for one-to-many distribution and frequently is not.

Multicast requires the switch to be doing IGMP snooping, so it knows which ports have subscribers and forwards the traffic only there. Without it, the switch treats multicast like broadcast and floods every port with every stream. On an unmanaged switch that means a 130 Mbps stream arriving at every device on the network, including the one running the lighting console and the one the venue uses for its EFTPOS terminal.

This is the single most destructive thing you can do to a show network, and it is a checkbox in the NDI settings that looks helpful.

So:

• Unicast by default. With three or fewer receivers per source, unicast is simpler and usually cheaper overall.
• Multicast only on a managed switch with IGMP snooping confirmed on, and with an IGMP querier present on the VLAN. If nobody can tell you whether snooping is enabled, the answer is unicast.
• Multicast earns its place when one source goes to five or more receivers — a programme feed to many confidence monitors, for instance.

The five switch settings that decide whether the show holds

1. A managed switch. Not a hardware snob’s preference — you need IGMP control, VLAN separation and the ability to see port statistics when something is wrong. An unmanaged switch is a box you cannot ask questions of.
2. Gigabit minimum everywhere, 10G where streams aggregate.
3. IGMP snooping on, with a querier, if multicast is used at all.
4. A dedicated VLAN for video. Not the venue’s network, not the guest network, not the network with the printers. This is the most valuable single item on this list.
5. Flow control off, jumbo frames left alone. Flow control can cause head-of-line blocking that stalls video. Jumbo frames sound like a benefit and cause problems when any device in the path disagrees about MTU. NDI does not need them.

Wi-Fi

Full-bandwidth NDI over Wi-Fi does not work reliably, and no amount of good Wi-Fi changes the fundamental issue: it is a shared medium with variable capacity, and video is a constant-rate stream that punishes variability.

NDI HX over good Wi-Fi at 8–20 Mbps is genuinely usable, for the things HX is for — a phone as a camera, a comfort feed, a monitoring position where a few frames of latency does not matter. Anything a presenter looks at, or anything going to the wall, gets a cable.

The other half of this: keep the venue’s Wi-Fi off the video VLAN entirely. A hundred delegates joining an SSID that bridges into your video network will find capacity you were relying on.

Discovery, and the thing that breaks it

NDI sources announce themselves via mDNS. It works with no configuration, which is why nobody thinks about it until it fails.

It fails when sources and receivers are on different subnets, because mDNS does not route. Symptom: everything is connected and pingable, and the source list is empty.

Two answers. Put everything on one subnet, which is the right answer for a show network and the reason to have a dedicated VLAN. Or run an NDI Discovery Server and point every machine at it, which replaces multicast discovery with a directory. For a permanent installation crossing subnets, the discovery server is the correct approach. For a touring rig, one flat VLAN is less to go wrong.

Diagnosing it on site

When NDI is misbehaving, in order:

1. Is the source in the list? No → discovery problem, look at subnets and mDNS. Yes → capacity or performance problem.
2. Check the receiver’s port utilisation on the switch. This is the number that tells you whether you have a bandwidth problem, and it is why you wanted a managed switch.
3. Reduce to one stream. If one is clean and six are not, it is capacity, not configuration.
4. Check for multicast flooding. If every port shows high traffic regardless of subscriptions, snooping is off. Switch to unicast immediately.
5. Check the sender’s CPU. A machine that cannot encode fast enough looks exactly like a network problem from the receiving end.

That last one catches people out regularly, which is why it is worth being deliberate about using NDI only where it is needed. If the destination is on the same Mac, Syphon costs nothing and involves no network at all — that decision is here, and where each frame of delay comes from is in the latency breakdown.