NDI adapters
Use NDI adapters to publish an SRT, RTMP, or video-call source as a named NDI output for a switcher, graphics system, multiviewer, or control room.
Choose this whenAn SRT, RTMP, or browser-guest source must appear as a named NDI output.
Use another module whenUse NDI Discovered Devices when the source already exists on the NDI network.
/api/restream/createBefore you start
All methods require a valid x-access-token. Configure NDI networking first, create the upstream SRT, RTMP, or video-call source, and keep its source ID.
What you can do
createandupdateselect the input and assign the NDI device name.getAll,getCount, andgetByIdinspect adapters.startandstopcontrol NDI publication.getStatchecks the running process.removedeletes an adapter.
Example workflow
{
"restream_name": "Remote camera to NDI",
"input": {
"input_type": "INPUT_TYPE_SRT_SOFTWARE",
"input_module_id": "SRT_SERVER_ID"
},
"output": {
"output_type": "OUTPUT_TYPE_NDI_DEVICE",
"output_settings": {
"ndi_device_name": "Remote Camera 1"
}
},
"module_name": "MODULE_NDI_ADAPTERS",
"active": true
}Create the adapter, start it, confirm runtime statistics, and then select Remote Camera 1 on the receiving NDI system.
Common use cases
- Bring an SRT field camera into an NDI-based control room.
- Expose an RTMP venue feed to an NDI graphics workstation.
- Publish a remote video-call guest as an individually selectable NDI source.
Limits and troubleshooting
The input resource must exist and provide usable media. Device names should be stable and unique enough for operators to identify. A saved adapter is not necessarily running; verify getStat before using it on air.
Next steps
Confirm the output on the receiving NDI system, then connect it to the required switching, monitoring, or recording workflow.
Bridge an NDI source into a delivery workflow
Create an adapter from a reviewed NDI source to the required output, start it, and verify the running process.
- Create the bridgeChoose the NDI input and the protocol and processing required by the destination.
POST /api/restream/create - Start the adapterStart after the NDI source and destination are available.
POST /api/restream/start - Verify the processRead the adapter runtime statistics before relying on the output.
POST /api/restream/getStat
A successful create response confirms configuration, not media health. Start the resource, then verify its runtime statistics before sending production traffic.
Configure NDI discovery, verify the network view, and publish an NDI output
Apply the instance discovery configuration, confirm expected NDI devices are visible, then turn a supported managed source into a named NDI output and verify the adapter process.
- Apply NDI network settingsSet the machine name, discovery servers, explicit source IPs, or the reviewed full JSON configuration.
POST /api/devices/updateNDIConfiguration - Verify the device inventoryList the current network view and confirm the expected names and addresses.
POST /api/devices/getAll - Check discovery activityConfirm the selected discovered row is currently active before relying on the network path.
POST /api/devices/getStat - Create the NDI publisherSelect a supported managed input and configure its OUTPUT_TYPE_NDI_DEVICE name and stream-control settings.
POST /api/restream/create - Start NDI deliveryStart the adapter after the managed source and target NDI network are available.
POST /api/restream/start - Verify the publisher processRead bitrate, FPS, speed, and progress before handing the NDI name to downstream operators.
POST /api/restream/getStat
A discovered-device row proves network visibility; its id is not the adapter input handoff. The released adapter examples accept managed SRT, RTMP GoPro, or conference-participant inputs and publish OUTPUT_TYPE_NDI_DEVICE.
Use this when a managed source must be published on the network as an NDI device for switchers, graphics systems, or other production clients.
The saved bridge uses the restream job fields with an NDI-device output and module_name: MODULE_NDI_ADAPTERS. A vMix Script example is available for operator-driven launches.
Use this preset when one managed SRT server should show up as a named Cloud NDI output.
This is the most direct operator-facing bridge from an existing SRT ingest boundary into an NDI device contract.
This is useful for hardware or software sources that already terminate on RTMP inside the platform.
Use this preset when one participant feed from a video call should be surfaced back into an NDI-aware production environment.
This is the conference-side variant of the same adapter pattern.
Dashboard label: Adapter name.
Human-facing name of the NDI adapter job.
Dashboard label: Source Input.
Real supported runtime families include managed SRT server inputs, managed RTMP server inputs, and conference-participant inputs.
Identifier of the selected source entity in the create form.
Dashboard label: Target Output.
This module pins the output side to OUTPUT_TYPE_NDI_DEVICE.
Dashboard label: NDI® Device Name.
Name of the Cloud NDI output device to create.
Dashboard label: Timestamp offset (ns).
Optional timestamp shift in nanoseconds.
Dashboard label: AV Stream Control.
Controls whether the adapter should publish audio, video, or both.
The UI saves this job as MODULE_NDI_ADAPTERS even though it uses the restream backend paths.
Dashboard label: Enable once created.
Controls whether the adapter should start active.
Identifiers and the saved adapter name.
Saved source definition for the adapter.
Saved NDI output definition for the adapter.
Module marker, active state, and backend-managed timestamps.
The model exposes success: true for successful responses.