Remote Production: SRT, NDI, Multiview & Failover | Callaba

A remote production workflow succeeds when the team can see every important handoff: contribution arriving from the field, production sources available to operators, the active programme path, the backup source, the recording, and each delivery output. This guide combines SRT contribution, Callaba-managed NDI operations, Multiview, failover, and recording into one bounded REMI workflow.

This page owns the implementation pattern. Use the Callaba remote production solution to evaluate the complete product, deployment choices, and business outcome. Individual SRT, NDI, Multiview, recording, and failover pages remain the owners of their respective product or protocol intent.

Define the REMI boundary before choosing protocols

List the source location, central production location, programme outputs, operators, and failure domains. SRT or RTMP can carry field contribution. NDI can connect compatible production tools inside an approved network design. Multiview gives operators a browser view of sources and outputs. Failover selects from a reviewed source set. Recording retains the programme or selected feeds.

This architecture does not imply bonded cellular, SDI, ST 2110, NMOS, genlock, or compatibility with every encoder and switcher. Those capabilities require separate verified components and acceptance tests. Use the actual equipment, software version, media format, and network path in the pilot.

Step 1: make field contribution measurable

1. Choose the contribution protocol supported by both the field encoder and Callaba workflow.
2. Record codec, container, resolution, frame rate, bitrate range, audio channels, latency budget, and addressing.
3. Configure access and network rules for the expected publisher rather than opening an unreviewed public input.
4. Start one representative field feed and inspect picture, audio, connection state, bitrate, and available transport history.

For SRT, Caller and Listener describe how the connection is established; they do not by themselves define which side sends the media. Document source and destination separately from the connection mode so field and central teams use the same vocabulary.

Step 2: operate NDI through the Callaba UI

Callaba includes NDI discovery, machine identity, network address settings, configuration import or editing, and NDI adapters in the product UI. That gives operators a reviewed way to manage the Callaba side of an NDI workflow without making terminal access the normal control surface.

1. Set the Callaba machine identity and approved discovery or network addresses.
2. Discover the intended NDI devices and confirm that duplicate or unexpected sources are not selected.
3. Create the adapter required by the production path and validate video, audio, timing, and naming at the receiving tool.
4. Preserve the reviewed configuration so it can be restored or reproduced before the next production.

NDI behaviour still depends on network design, bandwidth, software versions, and compatible senders and receivers. UI control reduces operational friction; it does not replace network engineering or interoperability testing.

Step 3: give operators one diagnostic view

Add the field source, backup, production return where appropriate, programme output, and important delivery outputs to Multiview. Label every tile by job, not only by protocol. “Field primary,” “Field backup,” “Programme,” and “Platform output” are faster to interpret during an incident than a list of port numbers.

Choose the signal facts operators will watch. A live picture is important, but it does not replace input state, bitrate, connection identity, and destination status. Agree who may switch sources and who owns the final programme decision.

Step 4: test recovery as a separate production layer

Prepare primary and backup sources in advance. Test automatic and manual switching with the real decoder and downstream production chain. Measure detection, transition time, audio, timestamps, keyframes, and destination recovery. Callaba does not make a universal hitless claim; the observed result depends on the complete path.

Step 5: attach recording and delivery deliberately

Decide whether to record the field feed, the selected programme, or both. Confirm storage, retention ownership, capacity, and playback before the event. Then create independent delivery jobs for the outputs required by the production. A failed social or partner destination should not require the operator to restart healthy contribution and recording jobs.

Cloud or self-hosted control

Use the cloud launch path for a fast proof or when a regional deployment fits the contribution and delivery topology. Use the self-hosted Linux path when Callaba must sit inside a production network or infrastructure boundary controlled by the team. In both cases, validate ports, bandwidth, storage, access, monitoring, and rollback.

API second layer: reproduce the reviewed path

After the UI workflow is stable, use the SRT contribution gateway recipe to provision and inspect contribution, the NDI configuration-to-delivery recipe for the approved NDI handoff, and the ingest, Multiview, and recording recipe to reproduce the monitored capture path. Automatic and manual failover remain UI-first in this public workflow: validate the source set and both controls in the product. Keep the human operating sequence and manual recovery path documented alongside automation.

Remote production acceptance checklist

• Every source, output, operator, and failure domain has an owner.
• Contribution codec, timing, audio, bandwidth, and latency are tested end to end.
• NDI discovery and configuration expose only the approved production scope.
• Multiview labels describe production jobs.
• Automatic and manual failover were rehearsed.
• Recording and each delivery output can fail or restart independently.