Video Compression in NDI
NDI is a transport protocol at its core, not tied to any specific codec. That means it can carry all kinds of media formats, compressed or uncompressed, depending on what the workflow needs and what the devices support. This flexibility makes it great for balancing image quality, network load, and latency.
NDI High Bandwidth (a.k.a. Full NDI)
In most professional setups, NDI uses its own intra-frame codec based on SpeedHQ, which was developed specifically for real-time production. It’s designed to give you high image quality with ultra-low latency.
It supports:
8-bit and 10-bit video
4:2:2 chroma subsampling
An embedded alpha channel for transparency
HDR video
Because each frame is compressed individually, there’s no delay caused by inter-frame dependencies. That keeps latency low (under one frame) and makes the stream robust against packet loss, perfect for switching, mixing, or editing live.
Rough bandwidth needs:
1080p60: around 125 Mbps
4Kp60: 250–300 Mbps
NDI HX is a more network-friendly version of NDI. It’s meant for devices with limited bandwidth, such as IP cameras, wireless links, or mobile gear. Depending on the hardware, it uses standard video codecs like H.264 or H.265.
It offers:
8-bit and 10-bit support
4:2:0 chroma subsampling (with optional alpha)
HDR support
Much lower bandwidth (typically 5–20 Mbps)
It’s fully compatible with the rest of the NDI ecosystem, and receivers automatically adapt to the stream.
NDI HX3 is the newest version of HX and a big step forward. Unlike earlier HX versions, HX3 has clearly defined compression, latency, and GOP structure specs, making it much more predictable and reliable for production use.
Key points:
Uses H.264 or H.265
Supports 8-bit and 10-bit color
4:2:0 chroma subsampling, with embedded alpha channel
HDR ready
Fixed GOP size: 20 frames
Latency: under 100 ms (glass-to-glass)
Bitrate:
1080p60: ~50 Mbps (H.265)
4Kp60: ~84 Mbps (H.265)
In short, HX3 provides high-quality video at lower bandwidth without compromising on latency or reliability.
NDI Audio
NDI wasn’t just made for video; it’s also a powerful tool for real-time audio over IP. It handles multiple audio formats, supports high channel counts, and keeps everything in sync with video without needing external timing protocols.
Audio formats supported:
PCM (uncompressed) – 48 kHz, 32-bit float, unlimited channels
AAC – compressed, up to 2 channels
Opus – compressed, up to 255 channels
All audio is carried together with the video in a single stream, so there’s no need for additional sync mechanisms like PTP. This design keeps audio and video tightly aligned—great for live production.
Internally, NDI always converts incoming audio to a consistent 32-bit float format, ensuring precision and compatibility.
Where NDI Audio Really Shines:
Live streaming & broadcast: Send commentary, talkback, and program audio over the same network.
Remote production: Use NDI Bridge to stream audio between locations with full sync.
Webinars & online training: Easy to set up, no specialized hardware required.
PA systems & Wi-Fi audio: Multicast-friendly, reliable, and scalable.
Home entertainment & wireless audio: Works better than many typical mDNS-based streaming setups.
Tools and Ecosystem
NDI Audio is becoming more versatile, with tools like:
NDI Virtual Sound Card – software audio I/O over NDI
NDI Audio Direct VST3 plugins – for DAW and real-time integration
NDI Audio lets you use the same infrastructure for video, audio, and metadata, making workflows more straightforward and flexible. It’s not here to replace precision AoIP systems in every case, but it’s more than enough for most production scenarios.
Metadata in NDI: Enabling Interoperability and Innovation
One of the lesser-known but most powerful features of the NDI protocol is its native support for metadata.
This capability enables devices and software to exchange structured information alongside video and audio, opening the door to remote control, automation, broadcast signaling, camera settings exchange, and many more applications.
Why Metadata Matters in NDI
NDI embeds Metadata directly into its transport stream using UTF-8 XML, a flexible and extensible format.
This enables:
Real-time control (e.g., camera iris, tally, PTZ position)
Transmission of auxiliary data (e.g., captions, subtitles, LUTs)
Integration with broadcast standards (e.g., SCTE, SMPTE)
Custom data exchange between systems (e.g., device IDs, scene names, tracking info)
This design is efficient, backward-compatible, and forward-compatible: unrecognized metadata is ignored, ensuring smooth communication between devices even when new features are added.
The Need for Standardization
Until now, metadata usage in NDI has been mostly ad hoc. Different vendors have implemented their XML schemas, often without clear documentation or guaranteed interoperability.
A new initiative proposes a structured framework for third-party metadata standardization within the NDI ecosystem to address this. The goal is to:
• Promote consistency across devices and applications
• Ensure interoperability and future-proofing
• Make metadata integration transparent, documented, and maintainable
A Platform for Third-Party Contributions
This effort includes the development of a public web portal where developers, manufacturers, and integrators can:
• Register and submit new metadata formats
• Provide usage examples and XML schemas
• Undergo a review and approval process
• Publish approved formats as part of the NDI standard
By formalizing this process, the NDI ecosystem opens up to collaborative development, ensuring that innovations in metadata, like camera control protocols or subtitle formats, can be shared and reused by the entire community.
By supporting third-party metadata integration through a clear and open process, NDI reinforces its position as a flexible, future-ready protocol that adapts to broadcast, pro AV, and beyond needs.
How NDI Routing Works
In a typical NDI workflow, the receiver selects which transmitter and stream to connect to, establishing a direct connection between the two devices. This is the most common and flexible way NDI works.
But there’s another approach: some software applications simulate a traditional video router, like the ones you’d find in an SDI environment.
These NDI routers act as “virtual sources,” allowing you to manage switching in a centralized manner, without physically routing any video.
A basic version of this is already available in the free NDI Tools package, under the name NDI Router. It allows you to define a virtual NDI source and select which real source it should point to, simple, effective, and ideal for many production scenarios.
So, how does it work?
Here’s the key point:
Although the routing software appears on the network as a source, it doesn’t send video itself. The video stream still flows directly from the original NDI transmitter to the final receiver.
What the router does is simulate an NDI source, and when you switch inputs, it tells all connected receivers to start pulling video from a different real source, behind the scenes.
It’s like a remote control for routing connections. The receivers never disconnect; they just start watching something new.
Why is this important?
The video never passes through the router machine, so it doesn’t use CPU, GPU, or network bandwidth for video processing.
Switching is instant and seamless, with no interruptions to the stream.
This model gives you the best of both worlds:
Receiver-based flexibility, plus centralized switching control, just like a traditional video router, but all in software, and all over IP.
Understanding the NDI Configuration File
Behind every NDI system, whether it’s a PC running production software or a tiny embedded camera, there’s something quietly working in the background: the NDI configuration file.
You won’t usually see it, but it plays a key role in how NDI behaves on a device.
Think of it like a control panel behind the scenes. It defines how your NDI device discovers other devices, how it broadcasts itself, and how it integrates into the larger network.
Where is this file?
Every NDI-compatible system has one.
On Windows or macOS, it’s managed by tools like NDI Access Manager.
On embedded systems or Linux, you typically configure it manually by editing a text-based configuration file.
It’s the same structure across platforms, so once you know how it works, you can use it anywhere.
What can the configuration file do?
Here are some of the things you can control using this file:
• Set up Discovery
You can tell the device how to find other NDI sources:
Use mDNS (default for local subnet)
Or use a Discovery Server for larger, multi-subnet networks
This is how you make sure your device knows where to look for streams.
• Create or join groups
NDI supports “groups”, think of them as visibility zones.
You can configure a device to only see or broadcast to specific groups, which is particularly useful when multiple productions or departments share the same network.
• Manually define remote sources
You can predefine the IP addresses or hostnames of NDI sources, perfect for networks that don’t allow mDNS, or when working across firewalls or VPNs.
• Enable and manage multicast streaming
By default, NDI uses unicast (one-to-one), but you can enable multicast to send a stream to multiple receivers more efficiently, especially in large venues or educational environments.
• Control the advertised stream name
Want your stream to show up with a specific name on the network? You can also set this in the config file. No need to rely on whatever the application decides to call it.
Understanding NDI Groups
In small NDI setups, everything “just works.” Devices discover each other, and all sources are visible to all receivers. But once your network starts to grow, with multiple studios, teams, or locations, you need a way to control who sees what.
That’s where NDI Groups come in.
What is an NDI Group?
An NDI Group is a simple but powerful way to control discovery visibility. It’s like a private channel for NDI sources and receivers:
• A sender can be placed in one or more groups.
• A receiver can be set to discover sources from specific groups.
If the sender and receiver don’t share a group, the source won't show up in the receiver’s list. This makes NDI groups essential when managing visibility in more complex environments.
Why Use NDI Groups?
NDI Groups are incredibly useful for:
• Keeping productions isolated from each other
• Avoiding accidental cross-feeds between departments or teams
• Managing visibility in multi-user or multi-purpose environments
• Organizing large deployments (e.g., different studios, classrooms, stages)
• Protecting unicast transmitters from overload: limiting access to a source reduces the risk of too many receivers connecting at once and potentially saturating the sender’s network interface
Groups give you control and structure, especially when your network has dozens (or hundreds!) of devices.
How to Set NDI Groups
Method 1 – Using NDI Access Manager (Recommended for Windows/macOS)
The easiest way to configure NDI groups is with the NDI Access Manager, included in the NDI Tools package.
Here’s what you do:
Open Access Manager
Go to the Groups tab
Enter the group names you want to assign:
• Send Groups: the groups this device will broadcast into
• Receive Groups: the groups this device will discover sources from
Method 2 – Using the NDI Configuration File (For Linux)
On systems, like Linux, where Access Manager isn’t available, group settings are defined manually in the configuration file:
ndi-config.v1.json
Here’s an example:
"groups": {
"send":
"Studio-A,Production-B",
"recv":
"Studio-A"
}
This means:
The device sends to both Studio-A and Production-B
But it only receives from Studio-A
A Few Things to Keep in Mind
Groups only affect discovery. If a receiver knows the IP and port of a sender, it can still connect, even if the groups don’t match.
So this is about visibility, not security.
Filtering happens on the receiver side. If a sender is in a group, it won’t be seen unless the receiver is also configured to look for that group.
The Groups string for each Send and Receive operation must not exceed 248 bytes in length, which means that the total length of the combined Group names should not exceed 248 characters.
Using NDI Groups is one of the best ways to scale your NDI deployment, maintain organization, and avoid surprises during production.
They’re simple to configure, but powerful when used well.
Understanding Synchronization in NDI
NDI transmitters and receivers do not require any specific synchronization method to connect and function. An NDI infrastructure can operate “sync-free”, avoiding the complexity and cost of network systems that support synchronization layers.
However, for specific use cases, developers and hardware manufacturers have several approaches to achieve synchronization.
When processing multiple video streams in production workflows, it may be necessary to synchronize all video streams to the same frame rate, with their frame start times aligned.
For physical video sources (e.g., cameras or video output cards) that have a fundamental native video timebase, synchronization is achieved through genlocking the internal video timebase to a reference signal, typically a blackburst signal.
For software-only implementations (e.g., character generators, DDR playback, graphics rendering engines) that lack an inherent internal video timebase, multiple platforms can maintain the same frame rate by locking system clocks using NTP, PTP, or similar protocols. However, even with locked system clocks, frame start times will not align across different applications since each application initializes its frame processing independently.
NDI Genlock offers a solution for software applications that lack an internal video timebase, enabling them to utilize an NDI signal as a timing reference. The Genlock instance connects to any visible NDI sender on the network and synchronizes the frame rate and frame start times to the selected source. The NDI source can reside on a local network, a remote network, or in the cloud.
To ensure proper operation of an NDI source as a Genlock reference, the following conditions must be met:
• NDI Version Compatibility
It is strongly recommended that the NDI source stream originates from NDI version 5 or higher, which includes significant enhancements for genlock support. Older NDI streams may not fully comply with NDI genlock operations.
• Network Bandwidth
The NDI source must have sufficient network bandwidth to provide the genlock stream to all NDI receivers. Configuring the source with multicast may help optimize bandwidth usage.
• Cross-Frame-Rate Locking
NDI Genlock supports cross-frame-rate locking, where, for instance, a 60Hz signal can synchronize to a 30Hz sender. However, this is not a recommended workflow and should be avoided if possible.
• Irregular Frame Streams
Some NDI sources, like the Test Pattern Generator and NDI Screen Capture, may not send a regular frame stream. These sources optimize CPU usage and save network bandwidth by skipping frames, making them unsuitable as genlock references.
• Fallback Mechanism
If the NDI Genlock clock cannot successfully synchronize with the NDI sender, it will automatically fall back to using the system clock. While this fallback is not as precise, it allows video processing to continue with reasonable performance.
Key Takeaways
• NDI does not require external sync (like PTP or blackburst) to function, making deployment cost-effective and straightforward.
• In software-only workflows, synchronization across applications is limited, even with system clocks locked, because frame processing starts independently.
• For hardware sources, traditional genlock (e.g. blackburst) is still required to align physical video signals.
• NDI Genlock offers a way to synchronize software-based applications by locking their timing to any visible NDI source on the network, even remote or cloud-based.
• Proper genlock behavior depends on factors like NDI version (v5+ recommended), network bandwidth, and avoiding irregular-frame sources.
• If NDI Genlock can’t lock to a source, it gracefully falls back to the system clock, maintaining continuity.
In short, NDI can run sync-free; however, when frame-level alignment is crucial, NDI Genlock is the tool that brings precision to software-driven production environments.
