Remote Production Workflow with SDI, NDI, SRT, and WebRTC

Build the workflow around jobs, not protocols

Remote production fails when teams start with a protocol list.

Start with jobs:

Capture the event
Move selected feeds to the control room
Give the director and producer low-latency monitoring
Send return video to talent
Record clean sources
Deliver the program feed
Keep audio in sync
Recover when the network drops packets

Then assign protocols.

SDI, NDI, SRT, and WebRTC each earn a place in the chain. Use them where they fit.

The baseline architecture

A practical remote production workflow often looks like this:

Venue:

SDI cameras -> capture workstation -> NDI inside the venue -> production encoder -> SRT to control room or cloud

Control room:

SRT receiver -> switcher or production app -> program output -> recording, streaming, monitoring

Remote users:

WebRTC preview for producers -> WebRTC return for talent -> HLS/DASH for viewers when scale matters

This design keeps high-bandwidth local production traffic inside the venue and uses SRT for the rough internet leg. It uses WebRTC only where people need fast browser access.

Step 1: Decide what must travel

Do not send every source across the internet because you can.

Create three groups.

Must cut live:

Main camera
Tight camera
Program feed
Clean feed
Key graphics source when the switch happens remotely

Must monitor:

Multiviewer
Audio meters
Talent return
Producer preview
Graphics preview

Nice to have:

Backstage cam
Wide safety cam
Screen share
Social clip source

The first group needs quality and resilience. The second group needs low latency. The third group needs limits so it never steals bandwidth from the show.

Step 2: Keep SDI where SDI works

SDI still solves simple problems inside venues. Cameras output SDI. Replay and hardware switchers often speak SDI. Operators understand cable length, frame rates, genlock, and routing.

Use SDI for:

Camera into capture hardware
Local program output
Confidence monitors
Hardware switcher inputs
Last-mile output to venue screens

Then convert at the edge. A capture workstation or encoder can ingest SDI and hand the signal to NDI, SRT, or another IP path.

Do not add IP complexity where a cable solves the problem.

Step 3: Use NDI inside the site

NDI helps when production software needs flexibility. A graphics machine can send a source to the switcher. A replay system can publish outputs. A multiviewer can pull sources without a full router setup.

Use NDI inside a controlled network for:

Software switchers
Graphics and lower thirds
Replay systems
Local multiviewers
Remote desktop production pods
Internal preview routing

Give NDI its own network plan. Use wired Ethernet. Avoid shared office Wi-Fi. Check switch capacity. Separate production traffic from guest internet when possible.

If you need to move NDI between sites, test NDI Bridge or convert to SRT. Do not assume the public internet will behave like a LAN.

Step 4: Use SRT for contribution

SRT handles the venue-to-control-room path well because it adds packet recovery over UDP and lets you set a latency buffer.

Use SRT for:

Camera contribution
Program backhaul
Cloud ingest
Encoder-to-decoder paths
5G and satellite links
Backup paths

Set latency based on the network, not ego. A 120 ms buffer sounds good on a sales call. A 500 ms buffer may save the show on cellular.

Run at least one rehearsal under real network load. If the event uses the same venue network as ticketing, Wi-Fi, press, or sponsor booths, test during a busy window.

Step 5: Use WebRTC for monitoring and return

WebRTC gives remote people a browser-based low-latency view. That makes it ideal for producers, directors, remote guests, talent, and engineering staff.

Use WebRTC for:

Producer confidence monitoring
Talent return
Director preview
Remote guest video
Low-latency browser multiviewer
Engineering checks from home

Plan TURN capacity. Direct peer connections do not always work. Corporate networks, hotels, airports, and mobile carriers can force traffic through a relay. TURN costs bandwidth twice: inbound to the relay and outbound from the relay.

If you ignore TURN, your workflow works in the office and fails on show day.

Step 6: Lock the audio plan

Remote production teams obsess over video and then lose time on audio.

Decide:

Who owns program audio
Where mix-minus comes from
How talent hears return
How intercom travels
What delay each person hears
How you verify lip sync

Do not send every audio path through the same channel. Program audio, intercom, and talent IFB have different needs.

Step 7: Add backups that operators can use

A backup path only counts if the operator can switch to it under pressure.

Good backup options:

Second SRT stream at lower bitrate
Cellular backup encoder
Audio-only fallback
HLS confidence feed
Local recording at the venue
Backup program return

Label everything. Give operators a one-page runbook. Include IP addresses, stream IDs, passphrases, phone numbers, and the exact failover order.

Step 8: Monitor from both ends

Watch the sender and receiver.

At the venue, track encoder load, upload bandwidth, packet loss, jitter, and dropped frames. At the control room, track decoder buffer, frame drops, audio sync, and stream uptime.

Put network metrics next to video preview. A clean picture without numbers gives false comfort.

A sample workflow

Small sports event:

Three SDI cameras feed a capture workstation.
The workstation publishes NDI sources on the local venue network.
The technical director selects two sources for remote contribution.
The system sends those feeds over SRT at 12 Mbps each with a 300 ms latency buffer.
The control room receives SRT, switches the show, records iso feeds, and outputs program.
Producers watch WebRTC previews in a browser.
Talent receives a WebRTC return feed at 720p.
Viewers receive HLS from the streaming platform.

That setup avoids one common trap: it does not force viewer delivery, production contribution, and return video through the same protocol.

Where Medialooks fits

Medialooks Video Transport handles low-latency movement of SDI and NDI sources over IP for production teams that need remote feeds without a full custom build.

Medialooks Video SDK fits teams building their own tools: ingest, playout, mixing, overlays, recording, WebRTC, SRT, NDI, RTMP, and hardware I/O inside one application.

Remote production rewards clean boundaries. Keep SDI and NDI close to the cameras. Use SRT for the long haul. Use WebRTC for people.