SRT
Encrypted, error-corrected video delivery over unpredictable networks.
What It Is
Secure Reliable Transport (SRT) is an open-source protocol developed by Haivision and open-sourced in 2017. SRT uses UDP transport with Automatic Repeat reQuest (ARQ) error correction to deliver video reliably over networks with packet loss, jitter, and fluctuating bandwidth — conditions that break TCP-based protocols like RTMP. SRT includes built-in AES-128/256 encryption, eliminating the need for VPN tunnels for secure contribution feeds. With 0.5–2 second latency and configurable error correction buffers, SRT is the standard for remote production, contribution feeds, and reliable first-mile delivery between broadcast facilities.
When to Choose SRT
Choose SRT when:
- You are sending contribution feeds over the public internet — SRT’s ARQ error correction handles packet loss that breaks RTMP.
- You need built-in encryption without VPN overhead — SRT’s AES encryption eliminates the need for separate VPN tunnels.
- You are doing remote production across unreliable networks — SRT’s configurable latency buffer lets you trade latency for reliability.
Consider alternatives when:
- You are ingesting to YouTube, Twitch, or Facebook Live — RTMP is what these platforms accept. SRT adoption is growing but not universal.
- You need sub-500ms latency for interactive use — WebRTC achieves lower latency at the cost of scalability.
Key Characteristics
| Full name | Secure Reliable Transport |
| Developed by | Haivision (open-sourced 2017) |
| Transport layer | UDP with ARQ (Automatic Repeat reQuest) |
| Typical latency | 0.5–2 seconds |
| Encryption | AES-128 / AES-256 (built-in) |
| Error correction | ARQ-based retransmission, configurable latency buffer |
| NAT traversal | Caller/Listener/Rendezvous modes for various NAT scenarios |
| Max bitrate | No inherent limit (network-bound) |
| Open source | MPL 2.0 (libsrt) |
| Typical use case | Contribution feeds, remote production, reliable first-mile delivery over unpredictable networks |
How Qencode Handles SRT
Qencode accepts SRT ingest as an alternative to RTMP for live streaming workflows. SRT’s reliability makes it ideal for high-quality contribution feeds that are then transcoded and packaged into HLS/DASH for delivery.
Combine SRT ingest with Simulcast for multi-platform distribution, or enable DVR Recording to archive SRT-ingested streams.
SRT vs. RTMP
| SRT | RTMP | |
|---|---|---|
| Transport | UDP (ARQ) | TCP |
| Latency | 0.5–2s | 3–5s |
| Encryption | AES-128/256 (built-in) | RTMPS (TLS) |
| Error correction | ARQ (configurable buffer) | TCP retransmit |
| Lossy networks | Designed for packet loss | Breaks under packet loss |
| Platform acceptance | Growing | Universal |
| Best for | Contribution feeds, remote production | Platform ingest (YouTube, Twitch) |
For a detailed RTMP breakdown, see RTMP.
Calculate cost of SRT Protocol
| Minutes streamed | Total Cost |
|---|---|
| 1 | $0.01 |
| Output resolution | 480 | | FPS | 30 |
| Transcoding(minutes streamed) | Cost/Minute |
|---|---|
| SDincludes 480p, 240p | $0.01 |
| HDincludes 1080p, 720p | $0.02 |
| Simulcast / Restream | Cost/GB |
|---|---|
| $0.04 |
Related Technologies
[**RTMP**
The established ingest protocol with universal platform support.](https://cloud.qencode.com/protocols/rtmp)
Simulcast
Distribute SRT-ingested streams to multiple platforms.
DVR Recording
Archive live SRT streams for on-demand playback.
We love creating powerful solutions that are aligned with the needs of your business.