Turn a remote SRT feed into an NDI source you can actually find and control
SRT is well suited to contribution across a WAN. NDI is designed around discoverable media inside a production network. Callaba can receive the SRT feed, create the NDI output and manage the discovery settings from its interface.
The conversion is only complete when the intended NDI receiver can see, open and decode the source.
The bridge has four distinct jobs
Accept the remote SRT publisher with the intended role, access policy and recovery window.
Confirm Callaba can decode the incoming video and audio before creating the NDI sender.
Give the NDI source a useful machine and source identity, then choose how it becomes discoverable.
Open the source from the real NDI receiver and check picture, audio, timing and sustained load.
Build the SRT-to-NDI path in Callaba
- Create an NDI adapter and identify the network interface and discovery policy it should use.
- Create the SRT server or input and send the intended contribution feed.
- Confirm the SRT session, incoming bitrate and decoded preview.
- Attach the SRT source to the NDI adapter and give the output an operator-readable name.
- Open an NDI receiver on the intended network and select the new source.
Use the NDI adapters user guide for current interface controls. The NDI adapter API recipe covers automation after the visual path works.
Discovery is part of the product, not an afterthought
Same network
NDI sources are often discovered automatically on a local network. Confirm that the sender and receiver share the expected discovery scope and network path.
Cloud, subnet or remote site
Automatic local discovery may not cross the boundary. Use an explicit Discovery Server or external-source design and keep firewall rules, interfaces and receiver configuration aligned.
The official NDI documentation explains Groups for controlling source visibility and the Discovery Server for centralized registration across networks. Callaba exposes relevant NDI network and configuration controls in the UI so an operator does not have to begin in a terminal.
Control visibility deliberately
A source name is not access control. Decide which networks and NDI groups may discover the sender, who can change the configuration, and whether the SRT contribution endpoint is restricted to known publishers. Restart behavior matters: NDI applications may need to reload changed configuration before the new discovery policy is visible.
Do not expose a cloud NDI environment broadly just to make the first receiver appear. Fix the discovery design instead.
Capacity must be tested with the intended media
Each bridge consumes decode, memory and network resources according to codec, resolution, frame rate, audio and number of outputs. Test the actual channel mix and watch CPU, memory and output continuity. A single successful HD source cannot establish capacity for multiple 4K feeds.
Source visible
The correct machine and source name appear only where intended.
Media usable
The receiver plays continuous picture and audio with the expected format.
Load understood
The instance remains within measured resource and network headroom.
Cloud NDI needs an explicit discovery plan
Local automatic discovery may not cross a cloud subnet or site boundary. Choose the interface, Discovery Server or external-source design deliberately; restrict visibility with the intended network and group policy; then open the source from the real receiver.
Capacity is also part of acceptance. Test the planned codec, resolution, frame rate and channel count while observing CPU, memory and network headroom. One working source is not a sizing result for the full deployment.
