NDI networking 25 min read

NDI: Networked Video Without Guesswork

Design NDI discovery, bandwidth, and distribution paths before a video network becomes an experiment.

Why an AV engineer should care

NDI can make a camera, playback system, graphics engine, or display destination appear to be only a few clicks away. That convenience depends on a network that can discover sources, carry the required streams, and keep ordinary traffic from becoming an unplanned bottleneck.

The useful question is not simply, “Does NDI work?” It is: which source is sending what bitrate to which receivers, across which links, using which discovery and distribution method?

Learning objectives

By the end of this lesson, you should be able to:

Separate NDI discovery from media transport.
Estimate NDI load at endpoint and uplink levels.
Choose unicast or multicast deliberately.
Recognize when mDNS, discovery services, or groups affect source visibility.
Turn a simple NDI diagram into a testable network plan.

1. Discovery is not the video stream

On a local network, NDI commonly uses mDNS to advertise and locate sources. A receiver that cannot see a source may have a discovery-path problem even when ordinary IP reachability is healthy. Routers and VLAN boundaries often do not forward mDNS by default.

For larger or segmented installations, NDI Discovery Server provides a unicast-based alternative to the default mDNS discovery process. It can make source visibility more deliberate and can avoid relying on multicast discovery across every segment. (NDI Discovery Server, NDI-FIND and mDNS)

Do not confuse “the source is listed” with “the network can carry the media.” Discovery, control, and media are related but distinct traffic paths.

2. Start with a traffic budget

NDI bitrate depends on version, codec mode, resolution, frame rate, content, and product implementation. NDI's current guidance describes a 1080p60 High Bandwidth stream as up to about 150 Mb/s; that is a planning input, not a universal constant. (NDI bandwidth guidance)

Calculate each potential bottleneck. For example, four cameras at up to 150 Mb/s each are approximately 600 Mb/s before protocol overhead and other traffic. A single 1 Gb/s uplink may be workable in one usage pattern and congested in another. Preserve margin for bursts, control, recording, multiview, and future sources.

A receiver's view matters too. A production workstation displaying four sources may receive four simultaneous streams. A recorder can be another receiver. Count actual simultaneous connections rather than only cameras.

3. Unicast is the default distribution model

In unicast mode, a source sends a separate stream for each active receiver. That is straightforward and often the right choice for one-to-one or small receiver counts. It also means sender and uplink traffic grows as receivers are added.

Practical example: a three-screen confidence feed

A 100 Mb/s camera feed requested by three independent receivers can require about 300 Mb/s from the sender in unicast mode. Before adding a fourth destination, check the sender interface, the access-switch uplink, and whether any receiver is traversing the same constrained link. NDI's switch guidance uses the same receiver-multiplication principle. (Recommended switch settings)

4. Multicast changes the replication point

NDI also supports multicast video sources. The sender emits one stream and switches replicate it toward participating receivers. It can improve a many-receiver distribution case, but it requires intentional network configuration: IGMP snooping, a working querier where appropriate, controlled multicast scope, and sufficient capacity on every carrying link.

NDI documents multicast as disabled by default and warns that incorrect multicast configuration can harm network performance. (NDI multicast guidance)

Use multicast because a measured receiver pattern and verified switch design justify it—not because it sounds like an automatic performance upgrade. If a switch floods multicast, unrelated ports can receive high-rate video they never requested.

5. Discovery scope and source visibility

Source groups and discovery configuration can limit what a receiver sees. That is useful for organization and can reduce accidental selection of the wrong camera or graphics source. It is not a substitute for VLAN, firewall, or access-control design.

When a source is missing, test in order:

Is the sender running and bound to the intended network interface?
Does the receiver have Layer 3 reachability to the sender or Discovery Server?
Is the intended discovery method configured consistently?
Are mDNS or Discovery Server settings appropriate to the network boundary?
Do group settings permit the receiver to see the source?
After selection, can the complete media path carry the stream?

6. Practical commissioning plan

Commission with an evidence trail rather than a roomful of open viewers:

Record each source's format, observed bitrate, and network interface.
Verify source visibility from every intended receiver.
Measure simultaneous receiver patterns, including multiviewers and recorders.
Monitor switch-port utilization, discards, and errors under load.
Test the intended unicast or multicast behavior explicitly.
Verify the failure path after an approved uplink or switch test.
Document Discovery Server address, group policy, and relevant firmware versions.

NDI-related ports and transport modes are product-version dependent; use the current official port reference when defining firewall policy rather than copying a generic range from an older design. (NDI related network ports)

Public-facing design and commissioning takeaway

A useful NDI schedule includes:

Source name, format, and maximum measured or specified bitrate
Sender and receiver network locations
Expected simultaneous receivers per source
Unicast or multicast behavior
Discovery method and Discovery Server address, if used
Group/source-visibility policy
Normal and failure-path link loads
Switch multicast and monitoring requirements

Practical exercise

Draw a path from one NDI camera to two viewers and one recorder. Assume a 1080p60 High Bandwidth stream budgeted at 150 Mb/s.

Estimate source output in unicast mode.
Mark every link that carries the stream.
Identify what changes if the three receivers use multicast.
List the evidence you would collect before approving the design.

Compact glossary

NDI: Network Device Interface, a networked media technology.
mDNS: Multicast DNS, commonly used for local source discovery.
Discovery Server: NDI service that provides unicast-based source discovery.
Unicast: Separate sender-to-receiver streams.
Multicast: One sender stream replicated by the network to receiver ports.
IGMP snooping: Switch feature that limits multicast forwarding to interested ports.
Uplink: Link between network layers or switches.

Review questions

Why can an NDI source be discoverable but still fail to play reliably?
How does adding receivers affect unicast sender load?
What switch behavior makes multicast safer than flooding it everywhere?

Answers

Discovery and media transport are separate; the media path can lack bandwidth or have a configuration problem.
Each active receiver can require another sender stream, so the load increases with simultaneous receivers.
IGMP snooping forwards a multicast group only toward ports with interested receivers, when the multicast control plane is correctly configured.

LIVE STREAMING PATH

A typical NDI live-streaming setup.

NDI formats: choose the workflow, not a marketing label

NDI High Bandwidth uses the SpeedHQ codec. It is designed for high-quality, very-low-latency work on a capable LAN, at the cost of more network bandwidth. NDI's published format guidance gives approximate 1080p60 and 4K60 values of 130 Mb/s and 250 Mb/s respectively; real traffic varies with the sender, format and content. (High Bandwidth format guide)

NDI HX is a family name for lower-bitrate workflows using H.264 or H.265/HEVC. You may encounter legacy HX1, then HX2 and HX3. They are not interchangeable labels for the same stream. Current NDI guidance lists HX2 around 11–16 Mb/s at 1080p60 and HX3 around 50–62 Mb/s at 1080p60, depending on codec; it also publishes format-specific latency targets. Treat those as format/certification references—not guarantees for a particular camera, decoder, switch path, display, or production application. (Format matrix, HX2, HX3)

A useful shorthand is:

Format	Typical trade-off	Check before specifying
High Bandwidth	More LAN bandwidth; high quality and low latency	NIC/uplink capacity and sender/receiver support
HX1 (legacy)	Older compressed workflow	Exact product and firmware compatibility
HX2	Lower bitrate compressed workflow	H.264/HEVC support, decode resources and latency
HX3	Compressed, lower-latency workflow	Exact codec, GOP/low-latency mode, sender/receiver support

Do not assume an NDI receiver supports every NDI format a sender can produce. Verify the exact device firmware, application version and enabled license/features. OBS Studio requires a compatible third-party integration—DistroAV is the current successor to OBS-NDI—and its required OBS and NDI Runtime versions are maintained separately. vMix has its own version-specific NDI input/output settings. (NDI's OBS guidance, vMix output documentation)

Read the streaming diagram as two separate networks

The diagram above intentionally splits the workflow in two:

Production LAN: NDI cameras and an optional HDMI/SDI-to-NDI encoder feed a managed Gigabit switch. The production PC receives, switches and mixes these sources. An audio mixer or USB/network audio interface can feed the production PC directly or be embedded through a compatible source. Local confidence monitors or return feeds also consume LAN capacity.
Internet contribution: OBS or vMix encodes the finished program and sends it to the chosen platform using that platform's required ingest method—often RTMP/RTMPS, or SRT where the destination supports it. NDI itself is not a native public-platform stream protocol.

Illustrative budget—not a universal design

Assume three 1080p60 High Bandwidth NDI cameras budgeted at 130 Mb/s each, one 30 Mb/s graphics source, and a production PC receiving all four:

Camera/graphics input to production PC: (3 × 130) + 30 = 420 Mb/s
Finished platform stream upload:       8 Mb/s, for this example

The 8 Mb/s Internet upload is not added to the NDI camera traffic on the camera-switch uplink; it is a separately encoded output from the production PC. But the production PC's NIC, its switch port, and any uplink that aggregates source traffic still need room for all simultaneous NDI receives, monitor/return feeds, overhead and bursts. Increase the network budget for additional independent receivers or NDI program/preview outputs. Recording an already-received source can add disk/CPU load without another network copy; verify how the application actually receives and records it.

Power and physical-network checks

Verify each PoE camera's required standard/class and maximum power against both the switch-port capability and the total switch PoE budget.
Prefer wired Ethernet for production NDI paths. Wi-Fi can be useful for deliberately tested, lower-bitrate contribution workflows, but changing RF conditions and retransmissions make it a poor default for primary cameras.
Use full-duplex Gigabit Ethernet or faster where the measured aggregate requires it. NDI advises Gigabit as a baseline and calls out higher demands for High Bandwidth 4K and HX3 4K workflows. (NDI switch guidance)
Measure the actual platform upload with a sustained test and leave operational headroom. An internet service's download speed says little about reliable outbound live-stream capacity.

A practical first commissioning run

Connect one wired NDI camera and confirm format, frame rate and measured bitrate at the production PC.
Add each camera one at a time while monitoring switch-port utilization, errors and discards.
Add audio, confidence monitoring and recording in the combination used for the event.
Start the final platform encoder at the intended bitrate and test the actual outbound path.
Review end-to-end delay at the destination, not only the NDI source-to-PC view.

This method exposes aggregate NIC, switch, PoE and Internet limits before an audience does.

Manufacturers: actual products, not blanket promises

NDI is supported across established camera and conversion manufacturers. These are examples of documented capabilities, not a shopping ranking or a claim that every product from the brand supports NDI. Verify the exact model, firmware, output mode and receiver before ordering.

Manufacturer / example	Documented NDI capability	What this illustrates
Panasonic AW-UE80	High Bandwidth and HX2 included as standard; supported output modes differ	One camera can offer more than one NDI workflow. Check the NDI output-format table, not just the camera sensor resolution.
Canon CR-N300	NDI HX2, with PoE+ connectivity	A PTZ can carry video, audio, control and power over one suitable Ethernet connection.
Sony BRC-AM7	Sony lists NDI HX support without an additional license charge from release	License policy is model-specific. Other Sony models may require a firmware update or license activation.
BirdDog X1 family	NDI HX3	A current compressed-NDI camera family; check the individual model's resolution and output options.
Magewell Pro Convert HDMI Plus	Converts HD HDMI into NDI High Bandwidth, with loop-through	An existing HDMI camera or other compatible unprotected source can join an NDI system without being an NDI camera itself.

An encoder creates an NDI source; a decoder turns a received source into an output such as HDMI. Some products do both, but do not assume that an encoder can also act as the overflow-room decoder. Likewise, a camera's available USB, HDMI, SDI and NDI modes may have different resolution limits or simultaneous-output restrictions.

NDI carries audio too

NDI is not silent video with an audio cable bolted on afterward. A source can carry audio alongside its picture, and compatible software can send or receive audio-only sources. The application decides which channels it exposes, how they are mixed, and whether they follow video switching.

NDI supports several audio codecs; practical channel count depends on the codec and product. A stereo camera feed is not evidence that every NDI endpoint is stereo, nor does a protocol's multichannel capability guarantee that a particular application exposes all those channels. Confirm channel mapping, sample rate and routing in the actual transmitter and receiver. 48 kHz is a common live-production choice. (NDI audio technical facts)

Keep the microphones from multiplying

For a simple streamed presentation, use one intentional program mix:

Microphones feed the mixer or DSP.
A USB audio interface, compatible network-audio input or camera embedding path brings that mix into the production computer.
Disable unused camera microphones and duplicate copies of the same mix.
Check left/right assignment and whether audio should remain constant or follow the selected camera.
Record a clap or slate, then adjust audio/video delay in the production software and listen to the finished recording.

A common mistake is accepting the same microphone through the mixer and two camera feeds. They arrive at different times, producing echo or comb filtering. More green meters do not mean better audio.

For remote guests, send a mix-minus return: the guest hears the host and program material, but not a delayed copy of their own voice. Keep local confidence-monitor speakers from feeding open microphones.

NDI audio is not Dante or AES67

NDI does not internally use the same PTP-synchronized model as Dante/AES67. Its receiver can compensate for clock differences, but independent NDI endpoints should not be assumed to provide sample-aligned speaker outputs. NDI's own guidance distinguishes its latency and synchronization behavior from dedicated low-latency network-audio systems. (NDI audio timing)

Practical rule: NDI is useful for production feeds, recorded/streamed program audio and software workflows. Do not substitute it blindly for a stage-monitor, distributed loudspeaker or other tightly synchronized live-audio design. Measure the complete path, including application buffers and conversion.

A Dante microphone does not appear as an NDI audio source merely because both share a switch. A compatible interface, licensed software or explicit gateway must receive one protocol and produce the other. Document that bridge and test its channel mapping, latency and clock behavior. See Lesson 20: Dante and AES67.

Free Windows tools you can actually use

NDI Tools is a free software collection. It does not make cameras, all NDI hardware upgrades, vMix licenses or third-party integrations free. Obtain the current installer from NDI, check its operating-system/GPU requirements, and review licenses before installing. Windows and Mac tool lists are different.

Start with a few tools rather than opening every application at once:

Windows tool	Useful job
Studio Monitor	View and hear a source independently of the production application. A good first test when the camera is visible but OBS/vMix is unhappy.
Test Patterns	Generate a known test source so you can check the receiving path without a camera.
Screen Capture	Turn a presentation computer's desktop and selected audio into a network source. Close private windows and notifications first.
Screen Capture HX	A lower-bandwidth screen-capture option; verify supported GPU/encoder requirements.
Webcam Input	Present a selected NDI feed to compatible applications as a webcam-style input. Verify the receiving app's audio/video selections.
Access Manager	Configure discovery/group and network-source settings. Groups organize visibility, not security.
Router	Assign sources to named virtual outputs and recall routing presets. It is not a video mixer or an IP router.
Bridge	Connect deliberate remote NDI workflows across locations. This is not the same job as sending a finished show to a streaming platform.

Sources and current platform list: Windows tools, Studio Monitor, Screen Capture, Screen Capture HX, Webcam Input, Router.

Audio Direct is a Windows-only collection of VST3 plug-ins for compatible audio applications. It can receive and generate multichannel NDI audio inside a supporting DAW. It is not automatically a system-wide replacement for every Windows audio driver. Audio Direct documentation.

NDI Free Audio is a separate command-line utility for connecting an audio interface to NDI, with Windows, Linux and Mac workflows. Its available channels depend on the audio device; distribution/setup differs by platform. This is a useful next step for an audio-focused lab, not the first application a beginner needs to open. Free Audio documentation.

NDI Analysis is a diagnostic utility available separately from the Tools Launcher. Old tutorials may also recommend NDI Remote, which the current documentation labels discontinued. Use the current download/support pages rather than an old bundle from a random mirror. Analysis, Remote status.

A free two-PC starter lab

On a trusted wired LAN, run Test Patterns or Screen Capture on PC A.
Open Studio Monitor on PC B and select that source.
Confirm picture and audio before adding production software.
Open a second receiver and observe how sender traffic changes.
If using OBS, install a compatible NDI integration such as DistroAV using its own current requirements; NDI Tools alone is not an OBS input plug-in.
Record locally and check lip sync before trying a public stream. Do not expose NDI services directly to the Internet to make discovery work.

Where this setup earns its keep

These are illustrative workflows, not manufacturer-specific system designs.

School studio or training room

Two PTZ cameras plus a teacher's Screen Capture feed enter the production PC. A USB mixer supplies the microphones. The operator switches camera/slides, records locally and sends one encoded program to the approved platform. Start with one receiver per source, then budget any additional preview stations.

House of worship or small live event

Stage cameras and a graphics/presentation computer feed the production switcher. A dedicated broadcast mix arrives from the audio console; it need not be identical to the room's PA mix. Send a local NDI program output to a compatible decoder for an overflow display, and a separately encoded stream to online viewers. Check the overflow audio delay and disable unused camera microphones.

Corporate town hall or hybrid meeting

Presenter cameras, slides and playback become production sources. A selected program feed can enter conferencing software through a compatible webcam-input workflow, while a separate stream/recording serves the broader audience. Remote presenters need a deliberate return video and mix-minus audio path; avoid routing the meeting's own received output back into its input.

Why the room screen is not the public stream

An in-room confidence or overflow display usually needs a local output path. Pulling the public stream back from the Internet can add substantial platform delay. A direct HDMI/SDI output or a tested NDI decoder path is generally the more controllable choice; verify end-to-end delay for the actual application.