What Is SRT Protocol? Secure Reliable Transport Explained

If you have ever lost a live stream because the venue Wi-Fi hiccupped, SRT is worth knowing about. So what is SRT protocol? Secure Reliable Transport is an open-source protocol for sending live video over unpredictable networks, such as the public internet, mobile data or satellite links, without the stutters and disconnects that plague older methods. Broadcasters use it to bring feeds from stadiums, newsrooms and remote studios. Increasingly, ordinary streamers use it too.

This guide explains how SRT works, the settings that matter, how it compares with RTMP and WebRTC, and how to use it in OBS and FFmpeg.

Where SRT came from

Haivision, a video technology company, developed SRT internally and released it as open source in 2017. The SRT Alliance followed, and today hundreds of companies support it in encoders, decoders, cloud services and media servers. Because the code is open, it has spread into FFmpeg, GStreamer, OBS, vMix, Wirecast and most professional hardware.

The problem SRT solves

The internet loses packets. Usually only a few, but live video is sensitive to every one.

RTMP, the long-time standard for sending streams to platforms, runs over TCP. TCP guarantees delivery by resending lost packets and holding everything else until they arrive. On a clean connection that is fine. On a lossy one, the stream backs up, the encoder’s buffer fills and frames are dropped, or the connection resets entirely.

Plain UDP does not wait, but it does not recover losses either, so the picture breaks up.

SRT sits in between. It runs over UDP but adds its own recovery, and crucially it lets you decide how long it may spend recovering.

How SRT works

A latency window you control

Every SRT connection has a latency setting, for example 500 milliseconds. The receiver holds incoming packets in a buffer for that long before passing them on. During that window, if a packet is missing, the receiver asks for it again, and the sender resends it. This is called ARQ (automatic repeat request).

If the resent packet arrives inside the window, the stream is perfect. If it does not, SRT gives up on that packet and moves on rather than stalling. The trade-off is explicit: more latency means more time to recover, fewer glitches and a longer delay.

Timing is preserved

SRT timestamps every packet, and the receiver releases them at the same pace the sender produced them. That keeps the output steady even when the network delivers packets in bursts, which matters for decoders and downstream servers.

Encryption built in

SRT can encrypt the stream with AES using a passphrase you share between both ends, with 128, 192 or 256-bit keys. Many broadcast feeds cross the public internet, so this is a real advantage over plain RTMP.

It carries anything

SRT does not care what is inside. Usually it carries an MPEG transport stream with H.264 or HEVC video and AAC audio, but it can carry other formats and multiple programmes too.

Connection modes

SRT connections have three modes, and choosing the right one solves most firewall problems.

Caller. This side starts the connection, like a browser visiting a website. Encoders in the field are usually callers.

Listener. This side waits for connections on a port. Servers and studio decoders are usually listeners. The listener needs an open UDP port reachable from the caller.

Rendezvous. Both sides call each other at the same time, which can get through some firewalls where neither side could accept an incoming connection. Less common, but useful for point-to-point links.

A typical setup: the camera encoder at a venue is the caller, the cloud media server or studio receiver is the listener.

Choosing the latency value

The rule of thumb is latency ≥ 4 × round-trip time (RTT), with at least 120 ms. Measure RTT with a ping to the server.

If you see artefacts or “packets dropped” statistics climbing, raise the latency in steps. If the link is clean and you want less delay, lower it gradually and watch the stats.

Packet loss also matters. On a link with a few percent loss, SRT needs extra bandwidth for retransmissions. Keep your stream bitrate comfortably below the link’s capacity; 25 percent headroom is a sensible minimum.

SRT compared with RTMP and WebRTC

• RTMP: simple, universally accepted by social platforms, but fragile on lossy links and unencrypted unless you use RTMPS.
• SRT: resilient, encrypted, tunable latency, codec-agnostic. Supported by professional tools and a growing list of platforms.
• WebRTC: sub-second latency and browser-native, but built for interaction rather than contribution feeds.

Our detailed comparison, RTMP vs SRT vs WebRTC, shows which to use in different scenarios. For how SRT fits into a full low-delay pipeline, see low-latency streaming explained.

Using SRT in OBS

OBS supports SRT output. In Settings → Stream, choose Custom, then enter an SRT URL provided by your server or platform, for example:

srt://ingest.example.com:9000?streamid=live/mykey&latency=500000&passphrase=yoursecret

Note that OBS takes the latency parameter in microseconds, so 500000 means 500 ms. The streamid identifies your stream on servers that host many at once. Set the encoder to CBR with a 2-second keyframe interval as usual; our OBS settings guide covers the rest.

Using SRT with FFmpeg

Sending a file or capture to an SRT listener:

ffmpeg -re -i input.mp4 -c copy -f mpegts \
  "srt://server.example.com:9000?mode=caller&latency=500000&passphrase=yoursecret"

Receiving as a listener and saving to a file:

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

The -re flag sends the file in real time, which is useful for testing. For real contribution you would read from a capture device or camera feed instead.

Where SRT fits in a streaming workflow

SRT is a contribution protocol: it gets video from the source to your processing point. From there, you still need to transcode and package for viewers, typically as HLS or DASH through a CDN. A common chain looks like this:

1. Camera or production switcher encodes H.264 or HEVC.
2. SRT carries the feed to a cloud media server.
3. The server transcodes an adaptive ladder.
4. A packager produces HLS and DASH.
5. A CDN delivers to viewers.

Many cloud services and open-source media servers, including SRS, MediaMTX, Nimble Streamer and Wowza, accept SRT ingest. Some social platforms accept it directly; check your platform’s current documentation.

Monitoring an SRT link

SRT exposes detailed statistics: round-trip time, packets lost, packets retransmitted, packets dropped because they arrived too late, and available bandwidth. Most tools show these live. The two numbers to watch are retransmission rate, which tells you how much the network is struggling, and dropped packets, which tells you the latency window is too small. If drops appear, raise the latency before blaming the encoder.

Common problems

Cannot connect. The listener’s UDP port is blocked. Open it in the firewall, or swap roles so the side behind the stricter firewall becomes the caller.

Connects, then picture breaks up. Latency too low for the network. Increase it.

Passphrase errors. Both ends must use the same passphrase and key length. Passphrases must be at least 10 characters.

High delay. Latency set far higher than needed. Reduce it gradually while watching dropped-packet statistics.

Bitrate collapses. The link is saturated. Lower the stream bitrate so retransmissions have room. Our bandwidth calculator helps you size it.

A real-world setup: streaming a conference from venue Wi-Fi

Imagine a two-day conference in a hotel. The venue offers shared Wi-Fi and a wired port in the AV booth, with an upload that swings between 15 and 40 Mbps depending on how many attendees are online. You want to stream the main stage to your own platform.

A sensible SRT setup looks like this. The production switcher outputs a 1080p30 feed to a hardware or software encoder set to 6 Mbps CBR with a 2-second keyframe interval. The encoder is the SRT caller. In the cloud, a media server listens on a UDP port with a passphrase. Round-trip time from the hotel to the server region measures 45 ms, so you start with an SRT latency of 800 ms, well above four times the RTT, to absorb Wi-Fi spikes.

During rehearsal you watch the statistics. Retransmissions rise during the coffee break when everyone checks email, but dropped packets stay at zero, so the latency window is doing its job. You also keep a bonded 5G modem as a backup path. The media server transcodes a ladder and publishes HLS, which viewers watch through a CDN.

Compare that with RTMP on the same network: the first Wi-Fi burst would likely have dropped frames or reset the connection. For a sense of the bandwidth involved at each stage, use the bandwidth calculator, and for protecting the delivered stream, see how to protect videos from being downloaded.

Summary

SRT, Secure Reliable Transport, is an open protocol for sending live video over imperfect networks. It runs over UDP, recovers lost packets within a latency window you choose, keeps timing steady and encrypts the stream. Set latency to about four times the round-trip time, pick caller and listener roles to suit your firewalls, and keep bitrate below the link’s capacity. Use it to carry feeds to your server, then deliver to viewers with HLS, DASH or WebRTC.