Remote Production with SRT and Starlink: A Field Guide

The Promise of Remote Production Over Starlink

Remote production has fundamentally changed how live events are covered. Instead of deploying a full production truck to every location, you send a small crew with cameras and encoders, then transport the video back to a centralized studio over the internet. The studio handles switching, graphics, replay, and distribution.

The missing piece for years was reliable internet at remote locations. Cellular bonding helped, but coverage gaps and congestion at crowded events made it unreliable. Then Starlink arrived, offering broadband internet almost anywhere on Earth with a pizza-box-sized terminal.

Combine Starlink’s reach with SRT’s resilience, and you have a remote production toolkit that works from a mountain summit, a rural stadium, or a beach wedding venue. This guide covers how to make it work in practice, including the pitfalls that documentation alone won’t tell you.

Understanding Starlink’s Network Characteristics

Before you plan your workflow, you need to understand what Starlink actually delivers in the field. It is not the same as a fiber connection, and pretending otherwise will cost you dropped frames.

Bandwidth

Starlink typically delivers 50-200 Mbps download and 10-25 Mbps upload, depending on location, congestion, and satellite visibility. For remote production, upload is what matters, and 10-25 Mbps is enough for one or two high-quality contribution feeds at 8-15 Mbps each.

However, bandwidth is not constant. Expect fluctuations throughout the day, especially at peak hours and in areas with dense Starlink adoption.

Latency

Starlink’s low Earth orbit satellites deliver round-trip times (RTT) of 25-60ms in most conditions. This is dramatically better than geostationary satellite (500-600ms RTT) and comparable to many terrestrial internet connections.

For SRT, this RTT range means you can work with latency buffers of 200-500ms and still get clean, reliable delivery.

The Challenges

Starlink has specific behaviors that affect live streaming:

• Satellite handoffs cause brief interruptions (typically 0.5-2 seconds) as the terminal switches between satellites
• Obstruction fading occurs when trees, buildings, or terrain temporarily block the satellite signal
• Weather sensitivity means heavy rain or snow can reduce throughput
• IP address changes happen periodically as Starlink reassigns your public IP through its CGNAT
• Buffer bloat can spike latency during congestion periods

None of these are deal-breakers, but they all need to be addressed in your workflow design.

SRT Configuration for Starlink

SRT was built for exactly this kind of unreliable network. The key is configuring it correctly for Starlink’s specific characteristics.

Latency Setting

For Starlink, set your SRT latency between 500ms and 1500ms:

srt://your-gateway:9000?mode=caller&latency=1000

Start at 1000ms. This gives SRT enough buffer to handle satellite handoffs and brief obstruction events without dropping packets. If your link is consistently clean, you can reduce to 500-750ms. If you are in an area with frequent obstructions, increase to 1500ms.

Refer to the SRT Latency Tuning guide for the detailed formula and methodology.

Encryption

Always encrypt over Starlink. Your traffic traverses Starlink’s ground stations and may cross multiple network segments:

srt://your-gateway:9000?mode=caller&latency=1000&passphrase=YourSecureKey2026&pbkeylen=32

Use AES-256. The CPU overhead is negligible, and you eliminate any risk of interception. See the SRT Encryption Setup guide for best practices.

Caller Mode

Your field encoder should always be in caller mode, connecting out to your studio’s SRT listener. This is critical because:

1. Starlink uses CGNAT, so you have no public IP to receive incoming connections
2. Caller mode works through NAT without any port forwarding
3. If the connection drops, the caller automatically reconnects

Your studio gateway (running Vajra Cast, for example) runs an SRT listener on a known port, and all field units call in to that address.

Overhead Bandwidth

Set oheadbw to 30-50% for Starlink:

srt://your-gateway:9000?mode=caller&latency=1000&oheadbw=40

This gives SRT room to retransmit lost packets during handoffs and congestion without starving the main stream. On a 15 Mbps link, 40% overhead means SRT can use up to 21 Mbps total, with 6 Mbps reserved for recovery.

Bandwidth Management

With Starlink’s limited and variable upload bandwidth, you need a deliberate encoding strategy.

Encoding Recommendations

Rule of thumb: Keep your total encoding bitrate below 60% of your measured Starlink upload speed. This leaves room for SRT retransmission overhead and bandwidth fluctuations.

Measuring Available Bandwidth

Before going live, test your Starlink link:

# Quick upload speed test
iperf3 -c your-server -u -b 20M -t 30

Run this for at least 30 seconds to capture any variability. Note both the average throughput and the minimum during the test period. Size your encoding bitrate to the minimum, not the average.

Adaptive Bitrate Encoding

If your encoder supports adaptive bitrate (ABR), enable it. This lets the encoder reduce quality during bandwidth dips rather than dropping frames entirely. Configure a floor bitrate that still produces acceptable quality, and a ceiling that matches your bandwidth budget.

Some hardware encoders like LiveU and BELABOX support this natively. Software encoders can use FFmpeg’s -maxrate and -bufsize parameters for similar behavior.

Failover Architecture for Unreliable Connections

The single most important principle for remote production over Starlink: never rely on one connection path.

Dual-Path Setup

The professional approach is to bond or failover between Starlink and a cellular connection:

Field Site:
  Camera → Encoder
    ├── SRT Caller → Starlink → Gateway (Primary)
    └── SRT Caller → LTE/5G  → Gateway (Backup)

Studio:
  Vajra Cast Gateway
    ├── SRT Listener :9000 (Starlink feed)
    ├── SRT Listener :9001 (Cellular feed)
    └── Failover logic: Primary → Backup, <50ms switch

Vajra Cast’s automatic failover monitors both inputs simultaneously. When the primary Starlink feed degrades (packet loss exceeds threshold, bitrate drops, or connection is lost), the gateway switches to the cellular backup in under 50ms. When Starlink recovers, it switches back automatically.

SRTLA Bonding

For maximum reliability, use SRTLA (SRT Live Association) bonding to aggregate Starlink and cellular into a single logical connection:

Field Encoder (SRTLA sender):
  ├── Starlink interface
  ├── LTE modem 1
  └── LTE modem 2
  All bonded → SRTLA → Gateway

Studio:
  Vajra Cast (SRTLA receiver) → distributes to production

SRTLA splits SRT packets across multiple network interfaces and reassembles them at the receiving end. If one path fails, the others absorb the traffic automatically. This is the same technology used by BELABOX encoders, and Vajra Cast supports SRTLA natively as both input and output.

With bonding, you get higher aggregate bandwidth and true path redundancy without discrete failover events.

The Slate Fallback

Always configure a slate or test pattern as a last-resort failover input in your gateway. If both Starlink and cellular fail simultaneously (it happens during severe weather), the gateway outputs a branded slate rather than a dead signal. This gives your production team something clean to cut to while waiting for connectivity to restore.

Real-World Deployment Tips

These come from actual field deployments, not theory.

Site Survey and Terminal Placement

Starlink needs clear sky visibility. Before the event:

1. Use the Starlink app’s obstruction checker at the exact terminal location
2. Aim for less than 1% obstruction time
3. Mount the terminal as high as practical, ideally on a tripod or mast above any obstacles
4. Orient it with the widest clear sky view toward the north (in the Northern Hemisphere)
5. Account for wind: Starlink’s flat terminal catches wind at height, so secure the mount

Power Planning

A Starlink terminal draws 50-75W in normal operation and up to 100W during snow melt mode. Combined with your encoder, monitor, and router, plan for 200-300W total at the field site. For events without shore power:

• A small portable generator (1000W) handles the full setup with margin
• Battery packs (like the EcoFlow Delta) provide 3-5 hours of runtime
• Bring at least 30% more power capacity than your calculated need

Pre-Event Testing

At least 2 hours before the live event:

1. Set up the full signal chain: camera, encoder, Starlink, SRT to gateway
2. Run a 30-minute continuous test stream
3. Monitor SRT statistics during the test, looking for packet loss spikes
4. Test failover by physically disconnecting the Starlink Ethernet cable
5. Confirm the slate fallback triggers if both paths fail
6. Document the observed RTT, packet loss rate, and available bandwidth

Network Isolation

Do not share the Starlink connection with anything else during the broadcast. Disable Wi-Fi on the Starlink router (or bypass it with a direct Ethernet adapter) to prevent other devices from consuming bandwidth. A single phone performing a cloud backup can consume your entire upload headroom.

Weather Contingency

Heavy rain degrades Starlink throughput and increases packet loss. Have a plan:

• Increase SRT latency buffer by 50-100% if rain is forecast
• Pre-configure a lower encoding bitrate profile that you can switch to quickly
• Ensure your cellular failover is working, as it is less affected by rain
• If thunderstorms are expected, have a plan to safely power down the terminal

Monitoring in the Field

You need visibility into what your link is doing in real-time, without requiring the field operator to be a network engineer.

Vajra Cast’s web dashboard shows per-stream metrics including RTT, packet loss, retransmission rate, and bitrate, all accessible from any device with a browser. The field operator can monitor from a phone or tablet, while the studio engineer sees the same data from the control room.

Key metrics to watch during a Starlink broadcast:

• RTT: Should stay between 25-80ms. Spikes above 150ms indicate congestion or a problematic handoff
• Packet loss: Under 2% is normal for Starlink. Over 5% sustained means increase your latency buffer or reduce bitrate
• Retransmit rate: Non-zero is expected and healthy. High sustained retransmit with zero packet loss means SRT is working perfectly
• Bandwidth utilization: Keep encoding bitrate plus SRT overhead below 70% of available upload

For deeper observability, Vajra Cast exposes a Prometheus /metrics endpoint. If you have a Grafana dashboard set up at the studio, you can track historical trends and set up alerts for degradation thresholds.

Case Study: Regional Sports Coverage

A regional sports network covers high school and college athletics across a state with limited venue infrastructure. Their challenge: produce broadcast-quality coverage at 15-20 venues per week, most without dedicated internet.

Their workflow:

• Field kit: 2 cameras, a compact video switcher, a BELABOX encoder with SRTLA, Starlink terminal, and a cellular modem
• Transport: SRTLA bonding over Starlink (primary) + LTE (backup), calling into a Vajra Cast gateway at the studio
• Studio: Vajra Cast receives the bonded feed, applies failover monitoring, and distributes via RTMP to their OTT platform and via SRT to their master control
• SRT settings: 1200ms latency, AES-256 encryption, 40% overhead bandwidth
• Result: Less than 0.1% downtime across 300+ events in a season

The total field kit costs under $5,000 and fits in two equipment cases. Compare that to a satellite uplink truck at $50,000+ per unit with $2,000+ per event in satellite time.

Bottom Line

Remote production over Starlink with SRT is not theoretical; it is the standard approach for an increasing number of productions worldwide. The combination of Starlink’s ubiquitous broadband and SRT’s resilient transport turns any location into a viable production venue.

The keys to success are: configure SRT for Starlink’s specific characteristics (higher latency, generous overhead), always have a failover path, test before every event, and monitor throughout the broadcast. With Vajra Cast handling the gateway, failover, and monitoring at the studio end, your field crew can focus on what matters: capturing great content.

For more on setting up the studio side of this workflow, see the SRT Streaming Gateway guide and the video failover best practices.