NDI, or Network Device Interface, is an IP-based technology for discovering and exchanging video, audio and metadata between compatible devices and software on a network. It is not a codec: the NDI formats use different codecs and involve different trade-offs in bandwidth, latency and image quality.
To try it, check that your sender and receiver support the same intended NDI format, install the relevant official tools or software, and test over a wired network if you can. NDI HX is one group of NDI formats, not a replacement name for NDI as a whole; its suitability depends on your equipment and workflow.
What NDI stands for
NDI stands for Network Device Interface. In practical terms, it is a way for compatible systems to make live media available to other systems over an IP network. A camera, media player or graphics computer can act as a source; a mixer, recording application or streaming computer can receive that source.
That description is broader than a cable connection between two boxes. NDI can support multiple sources on a shared network, and receiving software can select among the sources it can reach. Depending on the format and devices involved, the exchanged data can include video, audio and metadata. The term names the connectivity technology and its ecosystem of formats and tools, not a single piece of hardware.
You do not need an NDI camera to use NDI. A compatible software sender or a suitable capture workflow may provide a source, while a camera with NDI support can send video directly. The important question is not whether a device is a camera, but whether its exact model and software support the format you intend to send and receive. Check the manufacturer’s specifications rather than assuming that any network camera supports NDI.
NDI is mainly useful when you want to move media between devices without making a separate physical video connection for every source. For example, a camera in one room might send a feed to a computer running a production application elsewhere on the same reachable network. That convenience does not remove the need to plan network capacity, source discovery and compatibility.
What NDI does on a network
An NDI sender publishes a source over an IP network. A receiving device or application finds a source it can reach, then consumes the media. In a small setup, that might mean one camera and one computer connected to the same local network. In a production room, it might mean several cameras, graphics systems and software sources available to a mixer.
The network is carrying media traffic, not merely commands to start a camera. That distinction matters: video sources can place meaningful demands on the network, especially when there are several of them. NDI’s formats differ in their bandwidth, latency and image-quality trade-offs, so the load depends on the format and how it is configured. Resolution, frame rate, number of sources and the network itself also matter. Do not treat one device’s successful test as proof that a larger setup will behave the same way.
NDI describes its operation as bidirectional and able to carry many streams over a shared connection. In practice, your sender and receiver still need a route between them and a way to discover the source. A firewall, separate network segments, multicast settings or device incompatibility can prevent a source from appearing even when both devices are powered on.
If you are using NDI to feed a YouTube production computer, distinguish that local media path from the computer’s outgoing YouTube connection. NDI gets a source from one compatible system to another; the streaming application then handles the broadcast connection. For a different workflow that sends a prepared file repeatedly, see this guide to preparing videos for a YouTube loop stream. A looped file and a live NDI camera feed solve different problems.
NDI is not a codec
A codec encodes or decodes media. NDI is not itself a codec. It is a connectivity technology that supports multiple formats, and those formats use codecs with different characteristics. The official NDI overview describes NDI High Bandwidth in association with SpeedHQ, and NDI HX formats with H.264/AVC and H.265/HEVC.
This distinction helps explain why “NDI compatible” alone is not enough detail when planning a workflow. A sender and receiver may both support NDI but differ in which formats they support. A camera might offer an HX mode while a software application expects another format, or a particular receiving tool may not support the device’s chosen mode. Confirm the specific format at both ends rather than relying on the general NDI label.
It also explains why you should be wary of universal claims about bitrate or latency. Different formats make different trade-offs, and actual results depend on configuration and network conditions. The official material does not provide one bandwidth figure that applies to every NDI source. If you need a particular image quality or timing behaviour, test the actual sender, receiver and network together.
For a production destined for a live broadcast, test the complete path: source into the receiving application, audio alignment, scene or mixer behaviour, and the outbound stream. If your software is OBS, the NDI documentation describes its OBS plugin as unofficial and points to a setup guide; do not assume every OBS release and plugin combination is supported. You can also review common fixes when a YouTube live stream will not start in Streamlabs Desktop, though NDI source discovery and a platform broadcast error are separate issues.
How compatible systems exchange media
The basic workflow has three parts. First, a sender makes a source available in an NDI format. Second, the receiver discovers or is configured to reach that sender. Third, the receiver selects the source and processes its media. The exact buttons vary by application, but the compatibility checks are much the same.
Start by writing down the source, receiver and intended format. For example: “This PTZ camera sends NDI HX to this production computer.” Then check the camera’s documentation for the supported NDI format and the receiving application’s current documentation for compatible input support. If you use a bridge, capture device or third-party plugin, check its documentation as well. Each additional component introduces another compatibility point.
Next, put both devices on a network where they can reach one another. On a simple local setup, connecting them to the same wired switch may be enough, but network policies can still affect discovery. On a larger network, the devices may be on separate subnets or isolated by a VLAN or firewall. A source missing from the receiver’s list is therefore not automatically evidence of a faulty camera.
When a source does not appear, check in a calm order:
- Confirm that the sender is publishing the intended source and that the receiver supports its format.
- Check that both devices are connected to the expected network and can communicate across it.
- Review firewall, VLAN, routing and multicast rules with whoever manages the network.
- Restart or reopen the relevant applications only after noting their current settings, so you do not lose useful clues.
- If discovery is the issue across network segments, investigate NDI Discovery Service and the network configuration rather than assuming it will bypass restrictions.
The same principle applies if you are using several devices: add one source at a time, verify it at the receiver, then increase the load and retest. A successful single-source check only confirms that basic discovery and media exchange worked under that test; it does not prove that the whole production will remain reliable overnight or under a heavier workload.
NDI and NDI HX basics
NDI HX is a family of NDI formats, not a separate name for all NDI connectivity. NDI’s format descriptions associate HX with H.264/AVC and H.265/HEVC, while NDI High Bandwidth is associated with SpeedHQ. These format differences affect bandwidth use, latency and image quality, and your particular equipment may support only some of the choices.
The NDI 5.6 white paper describes HX as offering similar video quality at a lower bit rate and notes that it can suit limited-bandwidth contexts such as Wi-Fi or WAN connections. Treat that as background on the format family, not as a performance guarantee for your camera or network. Your image, latency and reliability depend on the device, settings and network conditions. Verify the exact model’s current specifications and test under the conditions in which you plan to use it.
Some PTZ cameras and mobile phones use HX, but that does not mean every camera or phone supports it. Nor does “HX” by itself tell you which codec version, resolution or other settings are available on a specific device. Ask the manufacturer or consult the model’s manual. NDI’s FAQ says it stopped selling NDI-HX upgrade licences on 31 December 2025; that policy does not tell you whether a particular camera already includes HX support or whether its manufacturer offers another upgrade route. Check with the manufacturer before buying on that assumption.
| What you are comparing | What to check | Why it matters |
|---|---|---|
| NDI High Bandwidth and HX | Supported format and codec at both ends | The labels refer to different format choices, not interchangeable settings. |
| Wired, Wi-Fi or WAN path | Network capacity and route between devices | The path can affect whether media and discovery work as intended. |
| Production use | Required image quality and acceptable latency | A format trade-off that suits one use may not suit another. |
| Device or software | Exact model, application and version support | General NDI compatibility does not confirm every format works. |
Choose based on the complete workflow rather than treating HX as automatically better or worse. A constrained network may make an HX option worth testing; a wired local workflow with different image or latency needs may lead you to another supported format. Let the sender, receiver and test results decide.
Install tools and confirm compatibility
NDI Tools is an official collection of utilities for NDI workflows. Download it from the NDI website rather than a third-party download site; NDI’s installation guidance warns that external download sites may not carry the latest release. Read the relevant tool’s current instructions and terms, particularly if your use is commercial. The tools documentation advises users with commercial-purpose questions to contact sales, so do not infer a blanket licence from a short description of the suite.
Installing tools is only one part of the setup. Identify whether you need a sender, receiver, monitor or configuration utility, then confirm that the particular application supports the format being sent. If you are using OBS, NDI’s documentation calls its OBS plugin unofficial and links to a setup guide. Check that guide and the plugin’s own compatibility notes for your OBS version before building a production around it.
A sensible first test is deliberately small. Connect the sender and receiving computer to the same wired network if available. Open the sender and make one source available, then use a receiving tool or application to check that it appears and plays. Confirm video, audio and any metadata you rely on. Note the selected format and settings so you can reproduce the test when something changes.
After the first source works, test the intended resolution, frame rate and number of sources, then leave the setup running long enough to observe the conditions that matter to you. Watch for dropped or delayed media, audio sync changes and whether sources remain visible after a device or application restart. This is not a certification of future performance; it is a way to identify a problem before a live production depends on the setup.
If you are building a complete YouTube channel rather than a camera-based production, consider whether NDI is needed at all. A prepared playlist streamed from a local player is a different arrangement, covered in this VLC guide to a 24/7 YouTube playlist. If your production genuinely depends on a live source, document the source and recovery steps so someone can diagnose it when the usual operator is away.
Network capacity and Discovery Service
NDI’s network-interface guidance suggests setting an adapter to 1 Gbps Full Duplex or higher where supported, to make the maximum available throughput possible. This is adapter guidance, not a universal per-stream bandwidth requirement or a promise that every gigabit network can carry any number of sources. The page also cautions that changing adapter properties can affect reliability positively or negatively and recommends testing with a network analyser before and after changes.
Actual capacity needs depend on the NDI format, resolution, frame rate, number of simultaneous sources and the network implementation. A network shared with other traffic may behave differently from a dedicated production network. Begin with the equipment you have, test the workload you intend to run, and ask the network administrator before changing managed switches, adapter settings or firewall rules. For a multi-device wired setup, a suitably sized Ethernet switch and cabling may be practical; size them for the number of connections and installation conditions rather than buying on a generic claim.
Discovery is another part of the network plan. On some local networks, multicast DNS helps NDI devices discover sources. Where multicast discovery is restricted or a workflow spans subnets, NDI Discovery Service may provide a centralised registry that can help systems find registered senders. The Discovery Service documentation explains its role and configuration options.
Discovery Service is not a tunnel through a firewall and does not remove routing, VLAN or device-compatibility restrictions. It can help with finding sources in an environment where ordinary discovery is unsuitable, but devices still need a permitted network path and compatible formats. If sources remain missing, involve the person responsible for the network and check the precise rules for the affected segments.
For a channel that runs continuously, decide who can check the physical and network setup if a source disappears. Record which device sends each feed, which format is selected, what receiver consumes it and whom to contact about managed network settings. For a different operational question—keeping a file-based channel running without a local computer—our guide to cloud hosting options for a 24/7 YouTube stream covers that separate decision. NDI itself is about media exchange between compatible systems; it does not make the broadcast or the surrounding network self-maintaining.
When a production depends on a computer staying on, watching the source and restarting a dropped broadcast can become a separate operational burden. StreamNeo addresses that specific burden for an uploaded-video workflow: it runs the file as a YouTube live stream without keeping your computer on. It is not an NDI receiver or a way to relay a live NDI camera feed.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Is NDI a codec?
No. NDI is an IP-based connectivity technology, and its formats use different codecs. Check the format and codec supported by both your sender and receiver rather than looking only for the NDI label.
Do I need a special NDI camera?
No. Compatible software or other equipment may send an NDI source, and some cameras include NDI support. Verify the exact device and format with its manufacturer; not every camera supports NDI.
Why can’t OBS see my NDI source?
Check that the sender is publishing, both systems can reach one another, and the source format is supported by your receiver and plugin setup. NDI describes its OBS plugin as unofficial, so consult its current setup and compatibility guidance rather than assuming every OBS version works.
Does Discovery Service fix sources that are missing?
It may help devices find registered sources when multicast discovery is restricted or a network spans subnets. It does not remove firewall, routing, VLAN or compatibility restrictions, so those still need to be checked.