Forem: Vajra Cast

RTMP to SRT Migration: Complete Step-by-Step Guide

Vajra Cast — Thu, 12 Feb 2026 16:02:20 +0000

Why Migrate from RTMP to SRT?

RTMP was designed for a different internet. SRT was built for unreliable networks with UDP transport, selective retransmission (ARQ), and built-in AES encryption.

What you gain:

Built-in encryption: AES-128 or AES-256, native to the protocol
Lower latency: UDP avoids TCP head-of-line blocking
Better error recovery: tolerates up to 30% packet loss
Real-time diagnostics: RTT, jitter, packet loss, bandwidth estimation
Bonding: SRTLA aggregates multiple connections

Before You Start

Inventory Your RTMP Endpoints

List every ingest point and output destination.

Check Encoder SRT Support

Encoder	SRT Support
OBS Studio	Yes (v27+)
vMix	Yes
Wirecast	Yes (v14+)
FFmpeg	Yes
BELABOX	Yes + SRTLA
Older hardware	Often no

Encoders without SRT need protocol conversion at the gateway.

Check Your Network

SRT uses UDP. Most corporate firewalls block it by default:

# Server side
nc -u -l 9000
# Encoder side
echo "test" | nc -u your-server.com 9000

Step 1: Set Up Your SRT Gateway

Use a gateway as the central conversion point. Migrate one encoder at a time.

Create SRT Listener on port 9000
Set latency based on network path (60ms LAN to 3000ms cellular)
Enable AES-256 encryption

Step 2: Configure OBS for SRT

srt://your-server:9000?latency=500000&passphrase=YourPassphrase&pbkeylen=32

OBS uses microseconds: 500ms = 500000.

Output settings: CBR, 6000 Kbps, keyframe 2s, zerolatency tune.

Step 3: Configure FFmpeg

ffmpeg -i input.mp4 \
  -c:v libx264 -b:v 6000k -g 60 \
  -c:a aac -b:a 128k \
  -f mpegts \
  "srt://your-server:9000?mode=caller&latency=500000&passphrase=YourPassphrase&pbkeylen=32"

Key: -f mpegts because SRT uses MPEG-TS, not FLV.

Step 4: Keep RTMP Outputs Where Needed

YouTube, Twitch, Facebook still require RTMP. Your gateway converts:

Encoder -> SRT (encrypted) -> Gateway -> RTMP -> YouTube/Twitch
                                       -> SRT  -> Production
                                       -> SRT  -> Recording

Step 5: Set Up Failover

With SRT real-time health metrics, detect degradation before full failure:

Packet loss: switch at >5% sustained for 2 seconds
Timeout: switch after 500ms of no data
Bitrate floor: switch if below 50% expected

Validation Checklist

[ ] SRT connection establishes
[ ] Encryption active (AES-256)
[ ] No unrecovered packet loss
[ ] Video plays cleanly on all outputs
[ ] Audio in sync
[ ] Failover tested
[ ] 4-hour duration test passed

Migration Timeline

Week	Action
1	Audit RTMP setup
2	Deploy SRT gateway, test
3	Migrate first encoder, run parallel
4	Validate, test failover
5	Migrate remaining encoders
6	Decommission RTMP ingest points

Migrate in parallel, not in-place. Run SRT alongside RTMP until confident.

More: SRT vs RTMP comparison | SRT Setup Guide

SRT Streaming Setup Guide: From Zero to Production

Vajra Cast — Thu, 12 Feb 2026 16:01:55 +0000

Why SRT

SRT (Secure Reliable Transport) has become the go-to protocol for professional video transport over the internet. If you are moving video between locations, SRT gives you reliability, encryption, and observability that RTMP cannot match.

Understanding SRT Modes

Listener Mode (Server)

The listener opens a port and waits for incoming connections:

srt://your-server:9000?mode=listener

Use when running a centralized gateway, accepting streams from multiple sources, or your server has a public IP.

Caller Mode (Client)

The caller initiates the connection:

srt://remote-server:9000?mode=caller

Use when you are an encoder sending to a server, behind NAT, or pushing to a specific destination.

Step 1: Choose Your Ports

SRT uses UDP. Convention is port 9000+, one port per listener. Ensure firewall allows UDP inbound.

Step 2: Configure Latency

The latency parameter controls the buffer size for error recovery:

Network Condition	Recommended Latency
LAN (<1ms RTT)	20-60ms
Same city (~5ms RTT)	120-200ms
Same continent (~30ms RTT)	250-500ms
Cross-continent (~100ms RTT)	500-1500ms
Satellite/Cellular	1000-4000ms

Rule of thumb: Set latency to at least 4x your round-trip time.

Step 3: Enable Encryption

SRT supports AES-128 and AES-256. Always enable over the internet:

srt://server:9000?passphrase=YourSecurePassphrase&pbkeylen=32

passphrase: 10-79 characters
pbkeylen: 16 (AES-128), 24 (AES-192), 32 (AES-256)

Both sides must match.

Step 4: Optimize Performance

Maximum Bandwidth: maxbw=10000000 caps at 10 Mbps including retransmissions.

Overhead Bandwidth: oheadbw=25 (default 25%). Increase on lossy networks.

Connection Timeout: connect_timeout=3000 for caller mode.

Monitoring Your Stream

Key SRT metrics:

RTT: should be stable
Packet Loss Rate: below 1% is good, SRT handles up to 30%
Retransmitted Packets: non-zero is normal
Available Bandwidth: estimated path bandwidth

Common Pitfalls

Latency too low: causes artifacts when SRT cannot recover packets
Firewall blocking UDP: SRT uses UDP, not TCP
Mismatched passphrases: connections silently fail
Wrong caller/listener: both sides must agree on roles

Next Steps

Set up automatic failover with a backup input
Configure multi-destination output
Explore SRTLA bonding for mobile production

Full protocol comparison: SRT vs RTMP

Video Stream Failover: Best Practices for Zero-Downtime Broadcasting

Vajra Cast — Thu, 12 Feb 2026 15:55:31 +0000

Why Failover Matters

In live broadcasting, a dropped stream isn't just a technical issue. It's lost audience, lost revenue, and damaged reputation. From a sports event with 50,000 viewers to a corporate town hall with 500 employees, the expectation is the same: it must not go down.

Video stream failover is the safety net that catches your broadcast when the primary feed fails.

What is Video Failover?

Failover is the automatic switching from a primary video input to a backup when the system detects a failure. A good failover system:

Detects failure fast: milliseconds, not seconds
Switches cleanly: minimal visual disruption for viewers
Recovers automatically: returns to the primary when it's healthy again
Requires no manual intervention: the whole point is automation

Architecture: Redundant Inputs

The foundation of any failover setup is redundant inputs. You need at least two independent paths:

Active/Standby

The simplest model. One input is active, the other is hot standby:

Primary SRT -> [Gateway] -> Output
Backup RTMP -> [Gateway] (on failure)

Active/Active

Both inputs carry the stream simultaneously. The gateway selects the best one:

Input A (SRT) -> [Gateway: compare] -> Best signal -> Output
Input B (SRT) -> [Gateway: compare]

More bandwidth cost, but higher reliability.

Detection: How Fast Can You React?

The speed of failover depends on how quickly you detect the problem:

Stream Health Monitoring

Monitor the incoming stream for:

Packet loss: SRT reports this in real-time
Bitrate drops: sudden decrease often precedes a full failure
Black/frozen frames: content-aware detection (advanced)
Audio silence: loss of audio signal

Timeouts

Detection Method	Typical Timeout	Notes
SRT packet loss	<50ms	SRT statistics report instantly
TCP disconnect	1-5s	TCP timeout dependent
Bitrate threshold	200-500ms	Configurable window
Content analysis	500ms-2s	Compute intensive

The 50ms Target

Professional broadcast equipment targets sub-50ms failover:

Failure detected within 20ms
Switch command issued within 10ms
Output buffer absorbs the transition within 20ms

At 50ms, the switch is invisible to viewers, happening within 1-2 video frames.

Implementation Patterns

Pattern 1: Gateway-Level Failover

The gateway itself handles failover logic. This is the simplest and most reliable approach:

Configure primary and backup inputs
Set detection thresholds (packet loss %, bitrate floor, timeout)
The gateway switches automatically and logs every event
When primary recovers, it switches back

Pattern 2: Encoder-Level Redundancy

Run two encoders independently:

Camera -> Encoder A -> SRT -> Gateway
Camera -> Encoder B -> SRT -> Gateway (backup)

Protects against encoder failure, not just network failure.

Pattern 3: Geographic Redundancy

For mission-critical broadcasts:

Venue Encoder -> SRT -> Gateway (Region A)
Venue Encoder -> SRT -> Gateway (Region B) [failover]

Both gateways output to CDN. CDN-level origin failover provides the final layer.

Monitoring and Alerts

Failover without monitoring is flying blind:

Real-time dashboards: visualize all input health metrics simultaneously
Automated alerts: get notified when failover activates (Slack, email, webhook)
Event logging: timestamp every switch event for post-mortem analysis
Recovery notifications: know when the primary is back

Testing Your Failover

Never trust a failover system you haven't tested:

Scheduled drills: pull the primary cable during a test stream
Network simulation: inject packet loss with tc to test SRT recovery vs. failover threshold
Encoder failure: kill the encoder process and measure switch time
Recovery testing: verify the system returns to primary
Load testing: confirm failover works under peak output conditions

Common Mistakes

Single point of failure in the switch itself: if your failover device fails, everything fails
Backup feed not monitored: your backup might be dead when you need it
Too-aggressive timeouts: switching on momentary packet loss creates unnecessary disruption
No automatic recovery: manual "switch back" means someone has to be awake at 3 AM
Not testing: the first time your failover fires shouldn't be during a live event

For more on SRT protocol fundamentals, see SRT vs RTMP: Which Should You Use?. For setup details, read the SRT Streaming Setup Guide.

OBS to SRT Streaming: Setup Guide for Low-Latency Broadcasting

Vajra Cast — Thu, 12 Feb 2026 15:53:47 +0000

Why Use SRT with OBS?

OBS Studio has supported SRT output since version 27, and as of version 30+ it is a first-class protocol option. If you are still pointing OBS at an RTMP endpoint, you are missing out on three significant upgrades:

Encryption: SRT encrypts your stream with AES-128 or AES-256 natively. No RTMPS certificate management, no TLS overhead. Just a shared passphrase.
Error recovery: SRT's selective retransmission (ARQ) recovers lost packets without retransmitting the entire stream. On a network with 2-5% packet loss, RTMP produces visible artifacts. SRT delivers a clean stream.
Real-time diagnostics: SRT exposes metrics like RTT, packet loss, jitter, and retransmission count. Your receiving server can monitor stream health in real-time and react before problems become visible.

This guide covers everything you need to connect OBS to an SRT destination.

Prerequisites

Before starting:

OBS Studio 30 or newer. Older versions have SRT support but with fewer configuration options and known bugs. Update to the latest version.
An SRT destination: a server running an SRT listener.
UDP connectivity. SRT uses UDP. If you are behind a corporate firewall that blocks outbound UDP, you will need an exception for your SRT port.

# Quick test: can you reach your server on UDP?
nc -vz -u your-server.com 9000

Step 1: Configure the SRT Destination

First, set up the receiving end. You need an SRT listener:

Choose a port (e.g., 9000)
Set latency to 500ms as a starting point
Enable encryption with a strong passphrase and AES-256

Your SRT endpoint is now: srt://your-server.com:9000

If you want to test quickly, you can use FFmpeg as a listener:

ffmpeg -i "srt://0.0.0.0:9000?mode=listener&latency=500000" -c copy output.ts

Step 2: Configure OBS Stream Settings

Open OBS and go to Settings > Stream:

Service: Select Custom...
Server: Enter your SRT URL with all parameters:

srt://your-server.com:9000?latency=500000&passphrase=YourSecurePassphrase&pbkeylen=32

Stream Key: Leave this empty. SRT does not use stream keys.

Critical: Latency Units

OBS specifies SRT latency in microseconds, not milliseconds. This is the single most common configuration mistake:

Desired Latency	OBS Value
120ms	120000
500ms	500000
1000ms	1000000
2000ms	2000000

If you set latency=500 in OBS, you are requesting 0.5ms, effectively zero buffer.

The Full SRT URL Explained

srt://your-server.com:9000?mode=caller&latency=500000&passphrase=MyPass123&pbkeylen=32&oheadbw=25

Parameter	Value	Description
`mode`	`caller`	OBS initiates the connection
`latency`	`500000`	500ms receive buffer in microseconds
`passphrase`	`MyPass123`	Shared encryption passphrase (10-79 characters)
`pbkeylen`	`32`	AES-256 (16=AES-128, 24=AES-192, 32=AES-256)
`oheadbw`	`25`	25% overhead bandwidth for retransmissions

Step 3: Configure OBS Output Settings

Go to Settings > Output and switch to Advanced mode.

Encoder Settings

x264 (Software Encoding)

Encoder: x264
Rate Control: CBR
Bitrate: 6000 Kbps
Keyframe Interval: 2 seconds
CPU Usage Preset: veryfast
Profile: high
Tune: zerolatency

The zerolatency tune disables x264's frame reordering and look-ahead features, reducing encoding latency by 2-5 frames.

NVENC (NVIDIA GPU)

Encoder: NVIDIA NVENC H.264
Rate Control: CBR
Bitrate: 6000 Kbps
Keyframe Interval: 2 seconds
Preset: P4
Profile: high
B-Frames: 0 (minimum latency) or 2 (better quality)

Intel QSV

Encoder: QuickSync H.264
Rate Control: CBR
Bitrate: 6000 Kbps
Keyframe Interval: 2 seconds
Profile: high

Why CBR?

SRT works best with Constant Bitrate encoding:

Bandwidth prediction: SRT allocates overhead bandwidth as a percentage of the stream bitrate. With CBR, this is predictable.
Packet scheduling: Constant bitrate produces evenly-spaced packets, which SRT can schedule efficiently.

Step 4: Resolution and Bitrate Guidelines

Resolution	Frame Rate	Minimum Bitrate	Recommended Bitrate
1280x720	30 fps	2500 Kbps	4000 Kbps
1280x720	60 fps	3500 Kbps	5000 Kbps
1920x1080	30 fps	4000 Kbps	6000 Kbps
1920x1080	60 fps	6000 Kbps	8000 Kbps
3840x2160	30 fps	15000 Kbps	20000 Kbps

Step 5: Latency Tuning

Measuring Your Baseline

Start streaming with latency=500000
Observe the reported RTT for 5 minutes
Note the average RTT and the peak RTT

Calculating Optimal Latency

Optimal Latency = 4 * Average RTT + 2 * (Peak RTT - Average RTT)

Example: Average RTT = 40ms, Peak RTT = 65ms

Latency = 4 * 40 + 2 * (65 - 40) = 160 + 50 = 210ms

Round up to 250ms. In OBS: latency=250000

Troubleshooting

"Failed to connect to server"

Wrong port: double-check the port number
Firewall blocking UDP: SRT uses UDP, not TCP
Passphrase mismatch: SRT silently rejects wrong passphrases
Server not listening: verify the SRT listener is running

Stream connects but video is broken

Latency too low: increase SRT latency
Keyframe interval too long: set to 2 seconds maximum

Intermittent freezing

Switch to a faster encoder preset
Use hardware encoding (NVENC, QSV)
Reduce resolution or frame rate

OBS SRT Quick Reference

Local Network (LAN)

srt://192.168.1.100:9000?latency=60000

Same City

srt://server.example.com:9000?latency=250000&passphrase=YourPassphrase&pbkeylen=32

Cross-Country

srt://server.example.com:9000?latency=800000&passphrase=YourPassphrase&pbkeylen=32&oheadbw=25

International

srt://server.example.com:9000?latency=1500000&passphrase=YourPassphrase&pbkeylen=32&oheadbw=30

For more on SRT fundamentals, read the full SRT vs RTMP comparison.

SRT vs RTMP: Which Streaming Protocol Should You Use in 2026?

Vajra Cast — Thu, 12 Feb 2026 15:49:59 +0000

The Protocol Dilemma

If you're building a live streaming workflow in 2026, you've probably asked yourself: should I use SRT or RTMP? Both protocols move video from point A to point B, but they do it very differently, and the right choice depends on your infrastructure, your audience, and your tolerance for dropped frames.

What is RTMP?

RTMP (Real-Time Messaging Protocol) was developed by Macromedia (later Adobe) in the mid-2000s. It became the standard for Flash-based streaming and remained the de facto ingest protocol for platforms like YouTube Live, Twitch, and Facebook Live.

Key characteristics:

TCP-based: reliable delivery, but vulnerable to head-of-line blocking
Low latency: typically 1-3 seconds in optimal conditions
Widely supported: virtually every encoder and platform speaks RTMP
No built-in encryption: relies on RTMPS (TLS wrapper) for security

RTMP works great on stable, low-latency networks. It's the "just works" protocol.

What is SRT?

SRT (Secure Reliable Transport) was developed by Haivision and open-sourced in 2017. It was designed from the ground up for unreliable networks: cellular bonding, satellite uplinks, and public internet connections.

Key characteristics:

UDP-based: avoids TCP head-of-line blocking
ARQ error recovery: retransmits only lost packets, not the entire stream
AES-128/256 encryption: built-in, not bolted on
Adjustable latency: you choose the buffer size based on network conditions
Bandwidth overhead reporting: real-time metrics on packet loss, jitter, RTT

SRT was built for the real world, where networks drop packets and bandwidth fluctuates.

Head-to-Head Comparison

Feature	RTMP	SRT
Transport	TCP	UDP
Encryption	RTMPS (TLS)	AES-128/256 native
Error Recovery	TCP retransmit (all)	ARQ (selective)
Latency	1-3s	Configurable (20ms-8s)
Firewall Friendly	Yes (port 1935)	Needs UDP ports
Packet Loss Tolerance	Poor	Excellent (up to 30%)
Bonding Support	No	Yes (SRTLA)
Adoption	Universal	Growing fast

When to Use RTMP

RTMP is still the right choice when:

You're ingesting to major platforms: YouTube, Twitch, and Facebook still prefer RTMP ingest
Your network is stable and local: LAN or dedicated circuits with <1ms jitter
Encoder compatibility matters: some older hardware only speaks RTMP
You need maximum simplicity: RTMP is "set the URL and go"

When to Use SRT

SRT is the better choice when:

You're sending over the public internet: SRT handles packet loss gracefully
You need encryption: AES-256 is built in, no extra infrastructure needed
You're doing remote production: SRTLA bonding lets you aggregate multiple cellular connections
You want real-time diagnostics: SRT exposes loss rate, RTT, jitter, and bandwidth metrics
Reliability is non-negotiable: SRT's ARQ ensures clean delivery even on lossy networks

The Best of Both Worlds

With a protocol-agnostic gateway like Vajra Cast, you don't have to choose. Accept both protocols simultaneously and convert between them in real-time:

Receive RTMP from legacy encoders, output SRT to your production network
Receive SRT from remote cameras, output RTMP to social platforms
Mix and match inputs and outputs across protocols

Plus, with automatic failover, if your primary SRT feed drops, the gateway switches to the backup RTMP input in under 50ms.

Bottom Line

Use SRT whenever possible. It's the modern choice: encrypted, resilient, and observable.

Use RTMP when platform compatibility or legacy equipment forces your hand.

Use both when you need maximum flexibility.