Remote Production: Produce Live Content from Anywhere

Build REMI remote production workflows with SRT, SRTLA bonding, Starlink compatibility, and low-latency video transport.

What is Remote Production?

Remote production (also called REMI, Remote Integration Model, or “at-home” production) is the practice of producing live content without sending the full production crew to the event location. Instead of building a complete control room at the venue, cameras and basic technical staff are on-site while directors, graphics operators, audio engineers, and producers work from a central facility, often hundreds or thousands of miles away.

The concept is straightforward: send raw camera feeds from the venue to the production hub, and send the finished program feed back out for distribution. The savings in travel, equipment transport, and personnel logistics are enormous. What makes it possible is reliable, low-latency video transport over the internet.

The REMI Workflow with Vajra Cast

A typical REMI workflow built on Vajra Cast:

Venue (On-Site):
  Camera 1 --> Encoder --> SRT --> Internet
  Camera 2 --> Encoder --> SRT --> Internet
  Camera 3 --> BELABOX --> SRTLA --> Internet
  Audio    --> Encoder --> SRT --> Internet

Cloud / Production Hub:
  Vajra Cast Gateway
    --> Receives all feeds
    --> Routes to production switcher (SRT/NDI)
    --> Provides monitoring dashboard
    --> Handles failover if any feed drops

Production Hub:
  Switcher --> Vajra Cast --> SRT/RTMP/HLS --> Distribution

The venue side is lean: cameras, encoders, and internet connectivity. The heavy lifting (switching, graphics, audio mixing, distribution) happens at the production hub where talent and infrastructure are permanently available.

SRT for Remote Production

SRT is the ideal protocol for remote production because it addresses the three core challenges:

1. Latency Management

Remote production requires low enough latency for the director to call shots in real-time. If the feed from the venue has 5 seconds of delay, the director cannot cue cameras effectively.

SRT’s configurable latency lets you optimize for your specific network path:

Network PathTypical RTTRecommended SRT LatencyEffective Glass-to-Glass
Same city5-15ms120-200ms200-400ms
Same country20-60ms300-600ms400-800ms
Cross-continent80-150ms500-1500ms700-2000ms

“Glass-to-glass” latency includes encoding, SRT transport, and decoding. For same-country remote production, you can typically achieve under 1 second total latency, fast enough for live direction.

For detailed latency configuration, see our SRT latency tuning guide.

2. Network Resilience

The internet between the venue and the production hub is unpredictable. SRT’s ARQ error correction handles packet loss without visible artifacts, as long as the latency buffer is sufficient. On a typical internet connection with 0.1-1% packet loss, SRT maintains a clean stream with modest latency settings.

For challenging networks (cellular, Wi-Fi, congested venues), SRTLA bonding provides additional resilience by aggregating multiple connections.

3. Security

Camera feeds for unreleased content, private events, or corporate communications need encryption. SRT provides AES-256 encryption natively, ensuring that even if someone intercepts the packets, they cannot decode the video. Read more in our SRT encryption setup guide.

SRTLA Bonding for Mobile Production

SRTLA (SRT Live Association) is a protocol extension that bonds multiple network connections into a single SRT stream. This is essential for mobile and field production where no single connection is reliable enough on its own.

How SRTLA Works

  1. The encoder (e.g., BELABOX, Vidiu, or a custom SRTLA sender) splits the SRT stream across multiple network interfaces
  2. Each interface sends its share of packets over a different path (cellular SIM A, cellular SIM B, Wi-Fi, Ethernet)
  3. The SRTLA receiver (Vajra Cast) reassembles the packets into a single stream
  4. If one connection drops, the others absorb the load

Vajra Cast as an SRTLA Receiver

Vajra Cast includes native SRTLA receiver support, compatible with BELABOX and other SRTLA-capable encoders:

  • Accepts bonded connections from multiple sender interfaces
  • Reassembles into a standard SRT stream for routing
  • Per-link statistics visible in the dashboard
  • No additional software or configuration required beyond enabling SRTLA on the ingest

Practical SRTLA Configuration

A field reporter at a remote location with unreliable connectivity:

BELABOX Encoder:
  --> 5G SIM (Carrier A): 15 Mbps
  --> 4G SIM (Carrier B): 8 Mbps
  --> Venue Wi-Fi: variable
  --> USB Ethernet (if available): variable

          |
          v (SRTLA bonded)

Vajra Cast Cloud Instance:
  SRTLA Ingest (Port 9000)
  --> Route to production hub (SRT output)
  --> Backup recording (HLS output)

With three or four connections bonded, you can sustain 10-20 Mbps aggregate throughput even when individual links fluctuate. The stream remains stable even if one connection drops entirely.

Starlink has transformed remote production in locations without terrestrial internet. A Starlink dish provides 50-200 Mbps download and 10-40 Mbps upload in most service areas, which is more than sufficient for HD or even 4K contribution feeds.

  • Latency: 25-60ms (LEO satellite, much lower than geostationary)
  • Jitter: moderate (10-30ms variations during satellite handoffs)
  • Packet loss: occasional bursts during handoffs, typically <1%
  • Upload: 10-40 Mbps sustained
SRT Latency: 500-1000ms
Overhead Bandwidth: 25-30%
Max Bandwidth: auto

The higher latency setting accommodates Starlink’s handoff jitter. SRT’s ARQ handles the occasional packet loss during satellite transitions. In practice, SRT over Starlink delivers broadcast-quality video with total latency under 1.5 seconds.

SRTLA + Starlink

For maximum reliability, bond Starlink with cellular:

BELABOX:
  --> Starlink (high bandwidth, occasional dropout during handoff)
  --> 5G SIM (lower bandwidth, stable during Starlink handoff)
  --> SRTLA bonded --> Vajra Cast

The two connections complement each other: Starlink provides bulk bandwidth while cellular covers the brief Starlink handoff interruptions.

Production Hub Configuration

At the production hub, Vajra Cast receives all venue feeds and routes them to the production infrastructure:

Vajra Cast (Production Hub):

  Input 1: "Camera 1" (SRT Listener, Port 9001)
  Input 2: "Camera 2" (SRT Listener, Port 9002)
  Input 3: "Field Reporter" (SRTLA, Port 9003)
  Input 4: "Audio Mix" (SRT Listener, Port 9004)

  Route "Program":
    Primary: Camera 1
    Backup:  Camera 2
    --> Output: SRT to production switcher
    --> Output: Recording (HTTP/TS)

  Route "ISO Camera 2":
    Input: Camera 2
    --> Output: SRT to production switcher (second input)
    --> Output: Recording (HTTP/TS)

  Route "Field":
    Primary: Field Reporter (SRTLA)
    --> Output: SRT to production switcher (third input)
    --> Output: Recording (HTTP/TS)

Each route has independent failover. The production switcher receives clean, monitored feeds from Vajra Cast. If any venue feed drops, the failover engages before the director even notices.

Monitoring Remote Feeds

When you cannot physically check the equipment at the venue, monitoring is everything. Vajra Cast provides:

  • Per-feed SRT statistics: RTT, jitter, packet loss, retransmission rate
  • Bitrate monitoring: detect encoder issues before they become visible
  • Connection state: know instantly when a feed disconnects
  • Failover event log: track every automatic switch with timestamps
  • VMAF quality scoring: verify video quality through the entire chain

All metrics are accessible via the web dashboard (accessible from anywhere) and the Prometheus endpoint for Grafana integration. Set up alerts for critical conditions:

  • Feed disconnection
  • Packet loss exceeding threshold
  • Bitrate dropping below minimum
  • Failover activation

Latency Optimization for Interactivity

For workflows that require real-time interaction (director calling shots, IFB/talkback audio, live interviews):

  1. Measure RTT between venue and production hub using ping or SRT statistics
  2. Set SRT latency to 4x RTT minimum (see our latency tuning guide)
  3. Use hardware decoding at the production hub to minimize decode latency
  4. Minimize processing stages. Each transcode step adds 100-500ms
  5. Consider separate low-latency feeds for talkback/IFB audio with aggressive latency settings

Next Steps

← Back to main guide