{"id":1204,"date":"2026-07-13T09:45:52","date_gmt":"2026-07-13T02:45:52","guid":{"rendered":"https:\/\/liveapi.com\/blog\/ndi-protocol\/"},"modified":"2026-07-13T09:46:24","modified_gmt":"2026-07-13T02:46:24","slug":"ndi-protocol","status":"publish","type":"post","link":"https:\/\/liveapi.com\/blog\/ndi-protocol\/","title":{"rendered":"NDI Protocol: What It Is, How It Works, and When to Use It"},"content":{"rendered":"Reading Time: <\/span> 10<\/span> minutes<\/span><\/span>

If you run video around a building \u2014 from a camera to a switcher, from a graphics machine to a recorder \u2014 you have two options. Pull physical SDI cable to every device, or send those signals over the network you already have. The NDI protocol<\/strong> is what makes the second option work.<\/p>\n

NDI moves broadcast-quality video, audio, and metadata between devices over standard Ethernet, with latency low enough for live switching. It replaced a rack of coax runs with a gigabit switch, and it has become the default way to connect gear inside a production facility.<\/p>\n

This guide explains what the NDI protocol is, how it works under the hood, its real bandwidth and latency numbers, how it compares to SRT and RTMP, and how to get an NDI feed off your LAN and out to viewers on the open internet.<\/p>\n

What Is the NDI Protocol?<\/h2>\n

NDI (Network Device Interface) is a royalty-free video-over-IP protocol that lets video devices discover each other and exchange high-quality, low-latency video, audio, and metadata over a standard Ethernet network.<\/strong> It was created by NewTek in 2015 and is now maintained by Vizrt.<\/p>\n

Instead of a dedicated SDI or HDMI cable between every camera, switcher, and monitor, NDI carries all of those signals over the same IP network your computers use. A single Cat5e or Cat6 run can carry dozens of bidirectional video streams, which is why NDI took over live production, houses of worship, corporate AV, and remote workflows.<\/p>\n

One important detail: according to the official NDI documentation<\/a>, NDI is a transport standard, not a single codec. It defines how sources are found and how frames travel across the network, and it uses different compression schemes (a proprietary intra-frame codec for full-bandwidth NDI, H.264 or H.265 for the lighter HX variants) depending on the mode you pick.<\/p>\n

Here is a quick reference before we go deeper:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Attribute<\/th>\nNDI<\/th>\n<\/tr>\n<\/thead>\n
Full name<\/td>\nNetwork Device Interface<\/td>\n<\/tr>\n
Created by<\/td>\nNewTek (2015), now maintained by Vizrt<\/td>\n<\/tr>\n
Type<\/td>\nVideo-over-IP transport protocol<\/td>\n<\/tr>\n
Network<\/td>\nGigabit LAN (standard Ethernet)<\/td>\n<\/tr>\n
Discovery<\/td>\nmDNS (Bonjour) + Discovery Server<\/td>\n<\/tr>\n
Transport<\/td>\nTCP, UDP multicast\/unicast, Reliable UDP<\/td>\n<\/tr>\n
Latency<\/td>\n~100 ms (full NDI on LAN)<\/td>\n<\/tr>\n
Bandwidth (1080p)<\/td>\n~100\u2013150 Mbps (full NDI)<\/td>\n<\/tr>\n
Licensing<\/td>\nRoyalty-free SDK<\/td>\n<\/tr>\n
Best for<\/td>\nVideo signal routing inside a facility<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

NDI vs SDI: Why the Protocol Exists<\/h3>\n

For decades, professional video ran on SDI (Serial Digital Interface) \u2014 a coaxial cable carrying one uncompressed signal in one direction. It works, but every new source means another cable, another run, and often another matrix router.<\/p>\n

NDI flips that model. Because it rides on IP, one network drop can carry many streams in both directions, and any device on the network can subscribe to any source. You add a camera by plugging it into a switch, not by pulling new coax. This is the same shift from point-to-point circuits to shared networks that reshaped telephony and data, applied to video signal routing. If you want the wider context on one-to-one versus one-to-many delivery, see our explainer on broadcast vs multicast<\/a>.<\/p>\n

How Does the NDI Protocol Work?<\/h2>\n

NDI handles three jobs: finding sources on the network, compressing frames efficiently, and delivering them with reliable, low-latency transport. Here is the sequence.<\/p>\n

1. Discovery.<\/strong> When an NDI source (a camera, an encoder, a software output) comes online, it advertises itself using multicast DNS (mDNS\/Bonjour). Every NDI receiver on the same subnet automatically sees a list of available sources \u2014 no IP addresses to type in. For sources on other subnets, a Discovery Server or manual NDI Access entry bridges the gap.<\/p>\n

2. Negotiation.<\/strong> A receiver requests a source. NDI then decides what to send based on need \u2014 a full-resolution program feed to the switcher, but a lower-resolution preview to a multiviewer. This “bandwidth on demand” behavior means idle or preview streams do not waste network capacity.<\/p>\n

3. Compression.<\/strong> NDI encodes each frame independently (intra-frame compression). Because no frame depends on the ones around it, encoding and decoding delay stays tiny \u2014 the trade-off is higher bitrate than the inter-frame compression used by delivery protocols. Full NDI uses NewTek’s proprietary SpeedHQ codec; NDI HX uses H.264 or H.265 for lower bitrates.<\/p>\n

4. Transport.<\/strong> Early NDI ran over TCP. Later versions added UDP multicast and unicast with forward error correction, Multi-TCP, and \u2014 since version 5 \u2014 Reliable UDP, which pairs UDP’s low latency with retransmission of lost packets. The result is TCP-like reliability without TCP’s head-of-line buffering.<\/p>\n

5. Metadata and control.<\/strong> NDI carries arbitrary metadata as XML alongside the video and audio. This is how features like PTZ camera control, tally lights, and closed-caption data travel on the same connection, in both directions.<\/p>\n

Because every step assumes a fast, stable LAN, NDI performs best on a dedicated gigabit (or 10-gigabit) network with proper multicast configuration. Push it onto a congested or high-jitter connection and quality degrades quickly \u2014 a limitation we cover below.<\/p>\n

NDI Bandwidth and Latency by Variant<\/h2>\n

There is no single “NDI bitrate.” The number depends on which flavor you use. Full (High Bandwidth) NDI prioritizes quality and latency; the HX family prioritizes low bandwidth for cameras and Wi-Fi links.<\/p>\n\n\n\n\n\n\n\n\n
Variant<\/th>\nCodec<\/th>\n1080p bandwidth<\/th>\nTypical latency<\/th>\nBest for<\/th>\n<\/tr>\n<\/thead>\n
NDI (High Bandwidth)<\/td>\nSpeedHQ<\/td>\n~100\u2013150 Mbps<\/td>\n~100 ms (near-zero on LAN)<\/td>\nWired switching, program feeds<\/td>\n<\/tr>\n
NDI HX<\/td>\nH.264<\/td>\n~8\u201320 Mbps<\/td>\n~200\u2013500 ms<\/td>\nPTZ cameras, bandwidth-limited links<\/td>\n<\/tr>\n
NDI HX2<\/td>\nH.264\/H.265<\/td>\n~10\u201320 Mbps<\/td>\n~200\u2013500 ms<\/td>\nEfficient camera contribution<\/td>\n<\/tr>\n
NDI HX3<\/td>\nH.265<\/td>\n~10\u201320 Mbps<\/td>\n~100 ms<\/td>\nLow-bandwidth with low latency<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

For 4K, full NDI climbs to roughly 200\u2013300 Mbps per stream, which is why 10-gigabit switches show up in larger installations. If latency budgets matter for your whole pipeline (not just the LAN leg), our guide to video latency<\/a> breaks down where the milliseconds actually go.<\/p>\n

A Short History of NDI Versions<\/h2>\n

NDI has shipped a steady stream of releases since its debut. Knowing the version history helps you understand what your gear supports.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
Version<\/th>\nReleased<\/th>\nKey additions<\/th>\n<\/tr>\n<\/thead>\n
1.0<\/td>\nApril 2016<\/td>\nInitial public, royalty-free SDK<\/td>\n<\/tr>\n
2.0<\/td>\nSept 2016<\/td>\nCross-subnet support (Access Manager)<\/td>\n<\/tr>\n
3.0<\/td>\nJuly 2017<\/td>\nNDI HX, multicast transport with FEC<\/td>\n<\/tr>\n
4.0<\/td>\nSept 2019<\/td>\nMulti-TCP transport, 16-bit HDR<\/td>\n<\/tr>\n
5.0<\/td>\nJuly 2021<\/td>\nReliable UDP, NDI Bridge, ARM\/Apple silicon<\/td>\n<\/tr>\n
6.0<\/td>\nApril 2024<\/td>\nHDR metadata, improved color<\/td>\n<\/tr>\n
6.3<\/td>\n2024<\/td>\nNative cloud transport<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

NewTek publicly revealed NDI<\/a> at IBC in Amsterdam in September 2015, then released the royalty-free SDK the following spring. That free SDK is a big reason adoption spread so fast across software and hardware vendors.<\/p>\n

Types of NDI<\/h2>\n

Beyond the version numbers, NDI ships in a few distinct forms. Picking the right one is mostly a bandwidth-versus-quality decision.<\/p>\n

Full NDI (High Bandwidth)<\/h3>\n

The original mode. It uses the SpeedHQ intra-frame codec for visually lossless quality and the lowest latency, at the cost of 100+ Mbps per 1080p stream. Use it for wired program and switching paths where you control the network.<\/p>\n

NDI HX, HX2, and HX3<\/h3>\n

The “High Efficiency” family compresses far harder using H.264 or H.265, dropping a 1080p stream to roughly 10\u201320 Mbps. That makes NDI practical over Wi-Fi and on PTZ cameras with modest onboard encoders. HX and HX2 add latency; HX3 brings latency back down near full-NDI levels while keeping the low bitrate.<\/p>\n

NDI Bridge<\/h3>\n

A tool that connects two entire NDI networks across the public internet through a single encrypted (AES-256) port using Reliable UDP. It effectively extends your LAN to a remote site without exposing raw NDI to the open internet.<\/p>\n

NDI HX drivers and NDI Tools<\/h3>\n

Free utilities \u2014 Scan Converter, Studio Monitor, Screen Capture, and the Virtual Input driver \u2014 let any computer produce or consume NDI without dedicated hardware. This is how many teams try NDI before buying encoders.<\/p>\n

Advantages of NDI<\/h2>\n

NDI’s popularity comes down to a handful of concrete wins over cable-based workflows.<\/p>\n

One network replaces many cables<\/h3>\n

A single Ethernet run carries dozens of bidirectional streams. Adding a source is a network task, not a cabling project, which cuts install cost and time on large builds.<\/p>\n

Low latency for live switching<\/h3>\n

Full NDI runs around 100 milliseconds and near-zero glass-to-glass on a clean LAN \u2014 fast enough for a director to cut between sources without visible lag.<\/p>\n

Bidirectional video, audio, and control<\/h3>\n

Video, multichannel audio, tally, and PTZ commands share one connection in both directions. You do not run separate control cabling for camera movement.<\/p>\n

Royalty-free and widely supported<\/h3>\n

The free SDK means no per-device licensing, and nearly every major production tool speaks NDI \u2014 OBS, vMix, Wirecast, TriCaster, and Adobe Premiere Pro among them.<\/p>\n

Bandwidth on demand<\/h3>\n

Receivers can request full or reduced-resolution versions of a source, so preview and multiview feeds do not consume full program bitrate.<\/p>\n

Cross-platform SDKs<\/h3>\n

Official SDKs cover Windows, macOS, Linux, iOS, tvOS, Android, Raspberry Pi, and even FPGA, so NDI shows up in everything from phones to broadcast ASICs.<\/p>\n

Disadvantages of NDI<\/h2>\n

NDI is excellent inside a facility and awkward outside one. Know the limits before you design around it.<\/p>\n

It is bandwidth-hungry<\/h3>\n

Full NDI at 1080p eats 100\u2013150 Mbps per stream, and 4K pushes 200\u2013300 Mbps. A handful of sources can saturate a gigabit link, which is why serious installs move to 10-gigabit networking.<\/p>\n

It needs a clean, fast network<\/h3>\n

NDI assumes low jitter and near-zero packet loss. On congested or poorly configured networks \u2014 especially with misbehaving multicast \u2014 quality drops sharply. It is not built to ride out a flaky connection the way SRT is.<\/p>\n

It is a LAN protocol, not an internet delivery protocol<\/h3>\n

Native NDI is designed for the local network. Sending it over the public internet requires NDI Bridge, a VPN, or the newer native cloud transport in 6.3 \u2014 and even then, NDI is not how you reach thousands of viewers. For that you convert to a delivery protocol (more on this below).<\/p>\n

Multicast configuration can be tricky<\/h3>\n

To get the network efficiency benefits, switches need IGMP snooping and querier settings done right. Get it wrong and multicast NDI can flood a network.<\/p>\n

NDI vs Other Streaming Protocols<\/h2>\n

NDI is often compared to internet streaming protocols, but they solve different problems. NDI routes signals inside a facility; RTMP, SRT, HLS, and WebRTC move video across the internet to viewers or platforms. Most real productions use NDI and<\/em> one of the others.<\/p>\n\n\n\n\n\n\n\n\n\n
Protocol<\/th>\nPrimary job<\/th>\nTypical latency<\/th>\nTransport<\/th>\nInternet-native<\/th>\n<\/tr>\n<\/thead>\n
NDI<\/td>\nSignal routing on a LAN<\/td>\n~100 ms<\/td>\nEthernet\/IP (RUDP)<\/td>\nPartial (6.3+)<\/td>\n<\/tr>\n
SRT<\/td>\nReliable contribution over the internet<\/td>\n0.5\u20132 s<\/td>\nUDP<\/td>\nYes<\/td>\n<\/tr>\n
RTMP<\/td>\nIngest to servers\/CDNs<\/td>\n2\u20135 s<\/td>\nTCP<\/td>\nYes<\/td>\n<\/tr>\n
HLS<\/td>\nDelivery to viewers\/VOD<\/td>\n6\u201330 s<\/td>\nHTTP\/CDN<\/td>\nYes<\/td>\n<\/tr>\n
WebRTC<\/td>\nInteractive, sub-second<\/td>\n<500 ms<\/td>\nUDP (P2P\/SFU)<\/td>\nYes<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The takeaway: use NDI for everything upstream of your switcher, then hand off to a contribution or delivery protocol for the last mile. If you are weighing the contribution options, our SRT vs RTMP<\/a> comparison covers the trade-offs, and the deep dives on the SRT protocol<\/a> and what RTMP is<\/a> explain each one on its own. For the viewer-facing leg, see what HLS streaming is<\/a>.<\/p>\n

Even RTSP fits here \u2014 it is the pull-based protocol many IP cameras speak before their signal ever reaches an NDI network. If that is your source, our guide to the real-time streaming protocol<\/a> is worth a read.<\/p>\n

\n

So far this has been about routing video inside<\/em> your walls. The moment you need an audience outside the building \u2014 on phones, browsers, and TVs anywhere \u2014 NDI hands off to a different set of tools. Here is how that handoff works.<\/p>\n

How to Stream NDI Over the Internet<\/h2>\n

You cannot send raw NDI to viewers. It is too heavy, too LAN-bound, and no consumer device plays it. Instead, you convert an NDI feed to a contribution protocol and push it to a streaming platform that transcodes and delivers it. The pattern looks like this:<\/p>\n

    \n
  1. Sources \u2192 switcher.<\/strong> Cameras, graphics, and playback machines send NDI to a software or hardware switcher (OBS, vMix, Wirecast, TriCaster).<\/li>\n
  2. Switcher \u2192 contribution protocol.<\/strong> The switcher outputs the program feed as RTMP or SRT \u2014 protocols built to survive the public internet.<\/li>\n
  3. Contribution \u2192 cloud ingest.<\/strong> That RTMP or SRT stream lands at a streaming API or media server in the cloud.<\/li>\n
  4. Cloud \u2192 viewers.<\/strong> The platform transcodes to adaptive bitrate<\/a> HLS renditions and delivers over a CDN so any device gets a stream matched to its connection.<\/li>\n<\/ol>\n

    This is the exact gap LiveAPI<\/a> fills. Your NDI production stays on the LAN where it belongs; your switcher sends the finished program out over RTMP or SRT, and LiveAPI ingests it, transcodes it instantly, and streams it to viewers worldwide through Akamai, Cloudflare, and Fastly. A basic OBS setup takes NDI inputs and points its stream output at a LiveAPI ingest URL \u2014 no separate media server to run.<\/p>\n

    # OBS\/vMix output settings (contribution leg)\nServer:     rtmp:\/\/ingest.liveapi.com\/live\nStream Key: <your-liveapi-stream-key>\n# LiveAPI ingests RTMP\/SRT, transcodes to HLS, and delivers via CDN\n<\/code><\/pre>\n
    From there you get the pieces NDI does not provide: multi-CDN delivery<\/a>, an embeddable player<\/a> for your site, multistreaming<\/a> to 30+ platforms at once, and automatic live-to-VOD<\/a> recording after the event ends. For lower glass-to-glass delay to the audience, pair the contribution leg with low-latency streaming<\/a> settings.<\/p>\n
    Tools and Software That Support NDI<\/h2>\n
    You do not need expensive hardware to start with NDI. The ecosystem spans free software to broadcast-grade gear.<\/p>\n