NDI — Network Device Interface

Network Device Interface

For detailed NDI architecture, codecs, and configuration, see ndi in the signal types section.

NDI is a video-over-IP protocol developed by NewTek (now part of Vizrt) that enables discovery, transmission, and reception of broadcast-quality video over standard Gigabit Ethernet networks. Unlike dedicated AV-over-IP systems requiring proprietary encoders/decoders, NDI runs as software on standard computers and on purpose-built hardware, making it uniquely flexible for production environments, streaming workflows, and corporate AV.

What NDI Does

NDI converts a video source (camera, graphics workstation, software application, capture card) into an IP video stream that any device on the same network can discover and receive — without pre-configuring IP addresses or setting up streams manually. Discovery is automatic using mDNS, similar to how Dante discovers audio devices.

A software application on one computer (OBS, vMix, Zoom, Microsoft Teams) can send its output as an NDI stream. Another computer on the same network can receive and use that stream as a video source — no capture cards, no video cables between machines.

NDI Versions and Codecs

NDI (original) — Visually lossless compressed codec. Approximately 100-250 Mbps bandwidth per 1080p stream. Designed for local network use; ultra-low latency (<5ms).

NDI|HX (High Efficiency) — Uses H.264 or H.265 at much lower bitrates (10-40 Mbps for 1080p), suitable for Wi-Fi and bandwidth-limited networks. Higher latency (100-300ms) than full NDI.

NDI|HX2 — Updated HX version with improved H.265 compression and lower latency than original HX. Common in current PTZ cameras with embedded NDI.

NDI 5 — Current major version. Adds NDI Bridge for internet transport and NDI Remote for direct peer-to-peer connections.

Where NDI Appears in AV Systems

PTZ cameras — Many modern PTZ cameras (PTZOptics, BirdDog, Lumens, Marshall) include NDI output alongside or instead of SDI/HDMI. These cameras appear directly in production software without a separate encoder.

Production software — NDI is natively supported in vMix, OBS (via plugin), Wirecast, Tricaster, Microsoft Teams (with NDI enabled in settings), Zoom (NDI output of local video feed), and hundreds of other applications.

Capture and conversion hardware — HDMI-to-NDI converters (Magewell Ultra Encode, BirdDog NDI converters) bridge legacy HDMI and SDI sources into NDI streams. NDI-to-HDMI converters output NDI streams to displays without a computer in the path.

Corporate AV — NDI enables campus-wide video distribution over the existing IP network: a camera in one conference room can feed to a lobby display or streaming encoder without dedicated video cabling.

NDI vs. Other AV-over-IP Protocols

Network Requirements for NDI

• Gigabit Ethernet — Each full NDI stream uses 100-250 Mbps. A system with 10 simultaneous sources needs switches with sufficient backplane capacity.
• IGMP snooping — NDI can use multicast for one-to-many distribution. IGMP snooping required on switches. See multicast-and-igmp-snooping.
• mDNS on local subnet — NDI discovery uses mDNS (Bonjour), which does not cross VLAN boundaries. All NDI devices must be on the same VLAN for automatic discovery, or an mDNS proxy must bridge VLANs. See discovery-protocols.
• Firewall rules — NDI uses a range of TCP and UDP ports. Windows Firewall must allow NDI traffic, or streams will appear discoverable but fail to connect.

Common Pitfalls

• mDNS discovery failing across VLANs — NDI devices on different VLANs cannot discover each other automatically. Use NDI Access Manager to manually add sources by IP, or configure an mDNS proxy.
• Gigabit congestion on shared networks — Full NDI streams from multiple cameras can saturate a 1 Gbps switch port or uplink. Use a dedicated production VLAN with its own switching infrastructure.
• NDI on Wi-Fi — Full NDI over Wi-Fi is unreliable due to bandwidth and latency variability. Use NDI|HX for Wi-Fi sources; use Ethernet for full NDI.
• Mixing NDI and NDI|HX sources — Full NDI (<5ms) and NDI|HX (100-300ms) sources appear in the same discovery list but have very different latency. Mixing them in live production creates visible timing offsets.
• Windows Firewall blocking streams — NDI discovery works (source appears in list) but clicking the stream fails to load. Almost always a firewall issue. NDI installs firewall rules automatically but Windows Defender updates sometimes reset them.