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 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 (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.

Ability to set NDI Groups

See Default discovery via "Public" Group.

Ability to enable or disable for Multicast broadcast

By default, a device should operate in mode, which means it opens a new transmitter within its software for every NDI stream that is requested. Multicast 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 is unique to NDI. It acts as a router to handle NDI traffic discovery and, therefore, NDI traffic. When enabled, any device pointed to that same Discovery Server may find any other device pointing to the same Discovery Server.

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 , 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 modes.

Abilty 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.