# Interoperability Requirements **Interoperability is the key criterion for certification**. Our team tests devices to ensure that with minimal knowledge or setup, NDI Certified equipment can “just work” with other NDI Certified equipment. The following items **must** be included to meet our interoperability requirements: ### Default DHCP When plugged into a network, the device or software must get an address from the DHCP[^1] server out of the box. Static can be an option but must not be set when the user receives the device. Most users expect to plug in a network cable and start operating with little ‘setup’ time. ### Separate Failsafe address A failsafe address is a separate static IP that the user can access if there is no DHCP server address given within 30 seconds of powering on. This is a static address that is accessible if the end-user connects a network cable directly to a PC in an ad-hoc environment. This is not the same as the static IP address that can be set for regular NDI traffic- for example, a device may have a failsafe address `192.100.100.25`, but can also be accessed via `10.20.14.23` if the DHCP server provides that address (or if the static IP address is set up correctly). ### Default discovery via mDNS Part of the core concept of NDI is that other NDI devices on the same network can easily identify an NDI source or receiver through [mDNS](/all/getting-started/white-paper/discovery-and-registration/mdns.md) (also called Bonjour or Zeroconf), meaning the end-user should not have to do any additional steps to find any NDI source. mDNS is not the only way a device can be found on the network, but if it is disabled, other discovery methods should be employed as long as the customer is informed either in the manual or some other way. ### Proxy Stream Part of the magic of NDI is that every device can provide a **low-latency, low-bandwidth dedicated preview stream** so a multiviewer doesn’t have to render every incoming preview at the highest resolution and waste limited resources when called on. The Proxy stream must always be available and not be disabled or turned off. ### Default discovery via "Public" Group This should be enabled by default. Like mDNS above, it facilitates auto-discovery of an NDI source—the difference being that mDNS is protocol agnostic—but the Public Group is unique to NDI. By the SDK standards, the default Group for any NDI source should be `Public`, so any receiver on the same network and in the same public group should find the NDI source. ### Default to "NDI mode" Some devices have NDI as a toggle, at the end-user's request. For a device to be Certified, NDI must be ‘on’ at default or out of the box. The user may be able to toggle it off at their prerogative, but the first boot and use should be “on” so it can “just work.” ### Ability to choose Static or Dynamic IP See [Default DHCP](#default-dhcp). ### Ability to set NDI Groups See [Default discovery via "Public" Group](#default-discovery-via-public-group). ### Ability to enable or disable for Multicast broadcast By default, a device should operate in Unicast[^2] mode, which means it opens a new transmitter within its software for every NDI stream that is requested. [Multicast](/all/getting-started/white-paper/multicast.md) should be a toggled option, which means the camera would have instead sent one stream of data, and the switch would handle the duplication of the data. Only the Transmitting device needs to have multicast as an option, but the receiving end should be set up to receive multicast. ### Ability to set Discovery Server(s) Like Groups, [Discovery Server](/all/getting-started/white-paper/discovery-and-registration.md) is unique to NDI. It acts as a central registry for NDI device discovery. When enabled, any device pointed to the same Discovery Server can find other devices also registered to it. ### Web or software-based GUI There must be a way to change settings on any NDI device, accessible via a web browser or specific software. There is no specific requirement for web, software, or app-based GUI[^3], as long as the method is documented and easily accessible. ### User manual Access to the intended user manual should be provided at the time of certification. This can be a paper manual, a link, or an attached PDF, but the certifier will use it to answer any questions they may have without needing to contact the licensee. Self-documenting/Tool Tips are sufficient if they can be called up when necessary. ### Update/Upgrade method Any NDI Certified device is expected to see **at least two minor or major revisions to NDI**, and there must be a user-accessible way to update the device to accommodate those changes. ### Factory Restore method The user may make enough changes to any device to render it useless in an NDI environment, whether intentionally or not. If the device is accessible via some GUI, a ‘factory restore’ or ‘reset default settings’ mode must be enabled to bring it back to the state certified by NDI. ### Up-to-date NDI SDK integration Whenever possible, any NDI Certified device should be running the most updated NDI SDK. Some older devices may be grandfathered in, if they were developed and released before a new version update. ### Works out of the box / in the lab overnight / over multiple days All the above ensures that when an end-user gets any NDI Certified device, it “just works” when plugged into their network. Then, the device must be left in a working and active state overnight or over a period of a few days and tested periodically to confirm that it still works, both in Unicast and [Multicast](/all/getting-started/white-paper/multicast.md) modes. ### Ability to use Embedded Bridge Introduced with **NDI 6** is the ability for a device to connect to any other device through NDI Bridge. Most devices will connect to NDI Bridge running on a PC, except for Switchers or Decoders, which may be considered bridge devices. Usually, NDI Bridge ensures that one NDI Network can connect to another NDI network seamlessly when configured properly, but some devices may add additional transcoding options. ### Ability to enable or disable HDR With the release of **NDI 6**, HDR is officially supported, but only on NDI 6 receivers. A device can send HDR video, but it must have a toggle to disable HDR (or a separate option to send the same video in HDR) in case it connects to devices running older NDI versions. ### Adherance to customer expectations for interlaced video (If interlaced-capable) For devices that support interlaced video formats, NDI remains a critical component for integration into legacy broadcast workflows. To maintain signal integrity in these environments, interlace-capable devices must ensure that fields 0 and 1 are transmitted at the regular intervals required to reconstruct a complete image. While the NDI SDK allows for both fields to be sent simultaneously, this configuration is only appropriate if the receiving workflow can process them without timing issues. Failure to manage field timing correctly in interlaced modes can result in dropped frames, duplicated frames, and/or degraded video quality. Devices that operate exclusively in progressive modes are exempt from these specific timing configurations. [^1]: **D**ynamic **H**ost **C**onfiguration **P**rotocol (DHCP) is a network protocol used to automate configuring devices on IP networks, thus allowing them to use network services such as DNS, NTP, and any communication protocol based on UDP or TCP. [^2]: In computer networking, unicast is a one-to-one transmission from one point in the network to another point; that is, one sender and one receiver, each identified by a network address. [^3]: A graphical user interface (GUI) is a digital interface in which users interact with graphical components such as icons, buttons, and menus. In a GUI, the visuals displayed in the user interface convey information relevant to the user, as well as actions that they can take. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.ndi.video/all/developing-with-ndi/ndi-certified/certification-guidelines/interoperability-requirements.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.