NDI
Studio-quality video over an ordinary network: found by mDNS, streamed frame by frame.
Finding sources: mDNS
The open-standard part of NDI, byte for byte: a multicast DNS question.
Whole frame
00 00 00 00 00 01 00 00 00 00 00 00 04 5F 6E 64 69 04 5F 74 63 70 05 6C 6F 63 61 6C 00 00 0C 80 01: how a receiver finds NDI sources: it multicasts this to 224.0.0.251, UDP port 5353, and every NDI sender on the subnet answers with its name and where to connect.
| Field | Offset | Example value | Meaning |
|---|---|---|---|
| Transaction ID | Byte 0–1 | 0 | mDNS (multicast DNS) reuses the DNS message format from RFC 1035, but its queries use ID 0: nobody replies to one specific asker, they answer the whole group. |
| Flags | Byte 2–3 | 0x0000 = query | All zero: a standard query. |
| Question count | Byte 4–5 | 1 | One question. |
| Other counts | Byte 6–11 | 0, 0, 0 | Answer, authority and additional counts: none in a question. |
| Label length | Byte 12 | 4 | Names are stored as labels each prefixed by its length. NDI advertises itself with the DNS-SD service type _ndi._tcp. |
| "_ndi" | Byte 13–16 | _ndi | The service name: every NDI sender announces itself as an _ndi service. The leading underscore marks it as a service rather than a host. |
| Label length | Byte 17 | 4 | Next label: 4 letters. |
| "_tcp" | Byte 18–21 | _tcp | The transport: the stream connection is TCP. |
| Label length | Byte 22 | 5 | Last label: 5 letters. |
| "local" | Byte 23–27 | local | The special top-level domain for the local link: names ending in .local are resolved by multicast, not by a DNS server. |
| End of name | Byte 28 | 0 | Zero-length label: the end. |
| Query type | Byte 29–30 | 12 = PTR | 12 = PTR: 'list every instance of this service'. Each answer is the name of one NDI source. |
| Class + QU bit | Byte 31–32 | 0x8001 = QU + IN | Class IN (1) with the top bit set: 'QU', meaning 'please answer me directly (unicast) rather than to the whole group'. Everyone else on the LAN is spared the reply. |
Overview
NDI (Network Device Interface) sends low-latency video, audio and metadata between computers and cameras over standard Ethernet. Any NDI source on the local network appears automatically in any NDI-aware app such as OBS, vMix or Resolume: nobody types an IP address.
Be aware that NDI is proprietary (Vizrt/NewTek). Its discovery uses open standards (mDNS / DNS-SD), which this page shows byte by byte. The media connection itself has no public wire-level specification, so we explain its structure schematically instead of inventing byte layouts.
Key facts
- Discovery
- mDNS / DNS-SD, UDP 5353
- Streams
- TCP, from port 5960 (UDP/multicast in newer versions)
- Codec
- SpeedHQ (full) / H.264, H.265 (HX)
- Bandwidth
- ~100+ Mbit/s per 1080p60 (HX: ~10–20)
- Latency
- About 1–3 frames
- Specification
- Proprietary (NDI SDK)
From discovery to video
The sequence of a receiver connecting to a sender. The media connection is drawn schematically because NDI's own format is not public.
Whole exchange
Discovery is open standard (mDNS); the media connection is NDI's own. A sender is announced once, and then any number of receivers on the network can pull its video.
1Who is sending NDI?
The receiver multicasts a standard DNS-SD question (the bytes on the previous scene). This part is public, standard Internet protocol.
2A source answers
The sender answers with its instance name (such as 'STUDIO-PC (Camera 1)'), an SRV record giving the TCP port (typically from 5960 upward), and an A record with its IP address.
3Open the stream connection
The receiver opens a TCP connection to the advertised address and port. From here on the format is NDI's own.
4Introductions (schematic)
The two ends exchange identity and capabilities and agree what to send: for example full-bandwidth or HX, whether audio is wanted. NDI's wire format is proprietary and not publicly specified, so this and the following steps are drawn schematically, not as byte layouts.
5A video frame
Frame after frame of lightly compressed video: full NDI uses the SpeedHQ codec (roughly 100+ Mbit/s for 1080p60); NDI|HX instead sends H.264/H.265 at a tenth of that. At 60 fps a frame is sent every 16.7 ms.
6Audio in the same stream
Audio travels with the video with timestamps, so lip-sync is kept without a separate connection.
7Control and tally flow backwards
NDI is bidirectional on one connection: the receiver can send small XML messages back (tally lights, PTZ camera control) without another channel.
Where you meet it
- Live production: cameras and computers into OBS, vMix, TriCaster
- Houses of worship, schools, esports and events using standard gigabit switches
- Video walls and projection mapping, sharing screens between machines
Watch out for
- mDNS does not cross routers. Sources on another subnet or VLAN need NDI Discovery Server (TCP 5959) or manually typed addresses.
- Full NDI at 1080p60 needs about 100+ Mbit/s per stream: a gigabit link fills quickly. Wi-Fi is not recommended.
- Allow mDNS (UDP 5353) and the NDI TCP/UDP ports through firewalls, or sources never appear.
- NDI|HX is lower bandwidth but adds latency and needs a hardware decoder or capable CPU.
Standards
- NDI documentation (ndi.video): network requirements and port usage
- RFC 6762: Multicast DNS
- RFC 6763: DNS-Based Service Discovery