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

Why Migrate from RTMP to SRT?

RTMP has been the default ingest protocol for live streaming since the Flash era. It works. It is supported everywhere. But it was designed for a different internet, one with reliable, low-latency connections between known endpoints. That is not the internet most of us stream over today.

SRT (Secure Reliable Transport) was built from the ground up for unreliable networks. It uses UDP instead of TCP, implements selective retransmission (ARQ) instead of full retransmit, and ships with AES encryption baked into the protocol. If you are still running RTMP for contribution feeds, remote production, or anything that crosses the public internet, you are leaving performance and security on the table.

Here is what you gain by migrating:

• Built-in encryption: AES-128 or AES-256, native to the protocol. No TLS wrapper, no certificate management, no external dependencies.
• Lower effective latency: SRT’s UDP transport avoids TCP head-of-line blocking. You can tune latency precisely with the latency parameter instead of hoping TCP behaves.
• Better error recovery: SRT’s ARQ only retransmits lost packets, not the entire stream. It can tolerate up to 30% packet loss with a sufficient latency buffer.
• Real-time diagnostics: RTT, jitter, packet loss rate, retransmission count, bandwidth estimation. All available in real-time, per stream.
• Bonding support: SRTLA lets you aggregate multiple network connections (cellular + Wi-Fi + Ethernet) into a single resilient stream. RTMP has no equivalent.

The question is not whether to migrate. It is how to do it without disrupting your existing workflows.

Before You Start: Assess Your Current Setup

Before changing anything, document what you have. You need to know:

1. Inventory Your RTMP Endpoints

List every RTMP ingest point and output destination:

Ingest Points:
  - rtmp://ingest1.example.com/live (main encoder)
  - rtmp://ingest2.example.com/live (backup encoder)

Output Destinations:
  - rtmp://a.rtmp.youtube.com/live2 (YouTube Live)
  - rtmp://live.twitch.tv/app (Twitch)
  - rtmp://recording-server.local/archive (local recording)

2. Identify Your Encoder Fleet

Which encoders are you using? Check their SRT support:

If any encoder does not support SRT, you will need to keep an RTMP ingest point for it and convert to SRT at the gateway level. This is exactly what a gateway like Vajra Cast handles: accepting RTMP from legacy devices and routing the stream as SRT internally.

3. Check Your Network

SRT uses UDP. This is the single most common migration blocker:

• Firewall rules: Most corporate firewalls allow TCP outbound by default but block UDP. You need UDP rules for your SRT ports.
• NAT traversal: SRT caller mode works through most NATs (it initiates the connection outbound). Listener mode requires port forwarding or a public IP.
• Port range: Convention is port 9000 and up. One port per SRT listener.

Run a quick test:

# On your server (listener side)
nc -u -l 9000

# On your encoder side
echo "test" | nc -u your-server.com 9000

If the packet arrives, UDP connectivity is confirmed.

Step 1: Set Up Your SRT Gateway

The cleanest migration uses a gateway as the central conversion point. This lets you migrate incrementally: move one encoder at a time without disrupting the others.

With Vajra Cast, create your first SRT ingest:

1. Open the web interface
2. Create a new ingest
3. Select SRT Listener as the protocol
4. Set the port (e.g., 9000)
5. Configure latency based on your network conditions:

6. Enable encryption. Enter a passphrase (minimum 10 characters) and select AES-256
7. Save the ingest

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

For a deeper understanding of SRT listener and caller modes, see our SRT Streaming Setup Guide.

Step 2: Configure OBS for SRT Output

OBS Studio is the most common encoder in the field. Here is how to switch it from RTMP to SRT:

OBS 30+ (Recommended)

1. Go to Settings > Stream
2. Set Service to Custom
3. Set Server to:

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

Note: OBS expects latency in microseconds, not milliseconds. So 500ms = 500000.

4. Leave the Stream Key field empty (SRT does not use stream keys)
5. Click Apply

Output Settings

For optimal SRT performance in OBS:

Output Mode: Advanced
Encoder: x264 or hardware (NVENC/QSV)
Rate Control: CBR
Bitrate: 6000 Kbps (adjust for your resolution)
Keyframe Interval: 2 seconds
Profile: High
Tune: zerolatency

CBR is important. SRT works best with constant bitrate because it can predict bandwidth requirements and optimize retransmission scheduling. VBR causes SRT to over-allocate overhead bandwidth.

Step 3: Configure Other Encoders

FFmpeg

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

Key parameters:

• -f mpegts: SRT transports MPEG-TS, not FLV (unlike RTMP)
• -g 60 -keyint_min 60: consistent keyframe interval (2 seconds at 30fps)
• mode=caller: FFmpeg initiates the connection to your gateway

vMix

1. Go to Add Output > SRT
2. Set hostname and port
3. Set latency (in milliseconds; vMix uses ms, not microseconds)
4. Enter passphrase and key length
5. Start output

BELABOX

BELABOX natively supports SRT and SRTLA. Configure the destination:

Protocol: SRT
Host: your-server.com
Port: 9000
Latency: 2000 (ms)
Passphrase: YourSecurePassphrase
Key Length: 32 (AES-256)

For SRTLA bonding (combining multiple cellular connections), see our dedicated SRTLA Bonding with BELABOX guide.

Step 4: Maintain RTMP Outputs Where Needed

Here is the critical insight: you do not need to migrate your outputs all at once. Many platforms still require RTMP ingest:

• YouTube Live: RTMP only (as of 2026)
• Twitch: RTMP primary, SRT not widely available
• Facebook Live: RTMP only

Your gateway handles this by accepting SRT on the ingest side and converting to RTMP on the output side. In Vajra Cast:

1. Create an output
2. Select RTMP Push
3. Enter the platform’s RTMP URL and stream key
4. Link it to your SRT ingest

Now your workflow looks like this:

Encoder → SRT (encrypted) → Vajra Cast → RTMP → YouTube/Twitch
                                        → SRT  → Production server
                                        → SRT  → Recording server

The critical contribution path (encoder to gateway) is encrypted and resilient. The last-mile delivery to platforms stays RTMP because that is what they accept. You get the best of both worlds.

Step 5: Set Up Failover

One of SRT’s biggest advantages is that it enables smarter failover. Because SRT reports stream health metrics in real-time (packet loss, RTT, jitter), a gateway can detect degradation before a full failure occurs.

Configure failover in Vajra Cast:

1. Create your primary ingest (SRT, port 9000)
2. Create a backup ingest (SRT, port 9001, or RTMP for a legacy backup encoder)
3. In the route configuration, set the primary and backup inputs
4. Set detection thresholds:
   • Packet loss: switch at >5% sustained for 2 seconds
   • Timeout: switch after 500ms of no data
   • Bitrate floor: switch if bitrate drops below 50% of expected

When the primary recovers, Vajra Cast switches back automatically.

For a deep dive on failover architecture, read Video Stream Failover: Best Practices.

Step 6: Validate the Migration

Before declaring the migration complete, run through this checklist:

Connectivity Checklist

• SRT connection establishes from encoder to gateway
• Encryption is active (check SRT stats for sndKmState: SECURED)
• Latency is within expected range (check RTT vs configured latency)
• No unrecovered packet loss (some retransmission is normal, drops are not)

Quality Checklist

• Video plays cleanly on all outputs
• Audio is in sync
• Keyframe interval is consistent (2-second max for platform compatibility)
• Bitrate matches encoder settings (check gateway metrics)

Failover Checklist

• Disconnect primary encoder. Backup activates within threshold
• Reconnect primary. Gateway switches back automatically
• Simulate packet loss (if possible) and verify SRT recovery

Monitoring Checklist

• Gateway dashboard shows all SRT metrics (RTT, loss, jitter, bandwidth)
• Alerts configured for connection drops
• Logging captures failover events with timestamps

Duration Test

Run the full workflow for at least 4 hours continuously. Watch for:

• Memory leaks (rising RAM usage on gateway)
• RTT drift (increasing latency over time)
• Reconnection behavior (does the encoder reconnect cleanly after a brief network interruption?)

Common Migration Issues and Fixes

”Connection refused” or no connection

Cause: Firewall blocking UDP. Fix: Open UDP on your SRT port. Test with nc -u first.

Stream connects but video is corrupted

Cause: Encoder sending FLV container instead of MPEG-TS. Fix: Set output format to MPEG-TS (-f mpegts in FFmpeg). SRT does not carry FLV.

High packet loss on SRT despite good network

Cause: maxbw set too low, starving retransmissions. Fix: Set maxbw=0 (auto) or increase to at least 1.5x your stream bitrate.

Latency is much higher than configured

Cause: Latency parameter is the minimum. Actual latency includes encoding delay, network jitter buffer, and decode time. Fix: This is expected. The latency parameter controls SRT’s receive buffer, not end-to-end glass-to-glass latency. Reduce encoder delay (use zerolatency tune) and decode-side buffering separately.

OBS shows “Failed to connect”

Cause: Passphrase mismatch or latency in wrong units. Fix: OBS uses microseconds. 500ms = 500000. Also double-check the passphrase matches exactly (no trailing spaces).

Migration Timeline

A realistic migration timeline for a mid-size operation:

The key principle: migrate in parallel, not in-place. Run SRT alongside RTMP until you are confident, then cut over. Vajra Cast accepts both protocols simultaneously, so there is no flag day.

What Comes After Migration

Once you are on SRT, new capabilities open up:

• SRTLA bonding for mobile production: aggregate cellular connections for reliable outdoor streaming
• End-to-end encryption without certificate infrastructure
• Real-time quality monitoring with per-stream metrics feeding into Prometheus and Grafana
• Intelligent failover based on stream health, not just connectivity
• Lower operational cost: fewer dropped streams means fewer emergency interventions

The streaming industry is moving to SRT. The SRT Alliance now includes over 500 member companies, and SRT support is standard in virtually every professional encoder shipped since 2022. Migrating now puts you ahead of the curve rather than catching up later.

For more on why SRT is replacing RTMP across the industry, read our SRT vs RTMP comparison.