What Is SRT Streaming? SRT vs RTMP Explained
SRT is a video transport protocol built to survive unreliable networks. Here's how it recovers lost packets, what the latency setting does, how it compares with RTMP, and why most platforms still ask for RTMP.
About 6 min read
On this page
SRT (Secure Reliable Transport) is an open-source protocol for sending live video over unpredictable networks such as the public internet. It runs over UDP, re-requests packets that get lost, lets you choose how much delay to trade for reliability, and can encrypt the stream. Broadcasters use it to move high-quality feeds between locations.
It isn't a replacement for RTMP everywhere, but it solves specific problems very well. Here's how it works and when it's worth using.
Key takeaways
- SRT uses UDP and recovers lost packets within a latency window you set.
- It suits long-distance or lossy links, such as remote venues and contribution feeds.
- Most creator platforms still document RTMP or RTMPS ingest.
- AES encryption with a shared passphrase protects SRT feeds in transit.
Where SRT came from and what problem it solves
SRT was developed by the video company Haivision and released as open source in 2017. It's now supported by a wide range of encoders, decoders, media servers and software, including OBS and FFmpeg.
The problem it targets is easy to describe: the public internet loses and reorders packets, especially over long distances, congested Wi-Fi or cellular connections. Traditional broadcast links avoided this with dedicated circuits or satellite capacity. SRT aims to deliver broadcast-grade reliability over ordinary internet connections instead.
It does that without caring much about what's inside the stream. SRT is a transport, not a video format, and it most commonly carries an MPEG transport stream containing H.264 or HEVC video with AAC audio. That flexibility helped professional workflows adopt it quickly.
How packet recovery and the latency buffer work
RTMP rides on TCP, which retransmits lost data but slows the whole connection whenever loss is detected. On lossy long-distance links, that shows up as stalls and buffering.
SRT uses UDP and handles recovery itself. The receiver holds packets in a short buffer. When it spots a gap in the sequence, it asks the sender to resend just the missing packet. If the replacement arrives before that moment of video leaves the buffer, nobody downstream notices.
The buffer size is the latency setting. Larger values tolerate worse networks at the cost of delay; smaller values keep delay low but drop packets that arrive too late. A common starting point is a few times the round-trip time between sender and receiver, raised for unstable links. Tools express latency in different units, so check the documentation.
Encryption, stream IDs and connection modes
SRT includes features that RTMP doesn't offer on its own:
- Encryption. AES with a passphrase both ends share, using 128-, 192- or 256-bit keys. RTMP needs the separate RTMPS variant to be encrypted.
- Stream ID. An optional identifier that lets one receiver port accept several feeds and route each correctly, a little like a stream key.
- Connection modes. One side listens on a port and the other calls it. A third mode, rendezvous, has both sides connect at once, which can help when both sit behind firewalls.
Because SRT uses UDP, the listener's UDP port must be open in every firewall along the way, unlike RTMP's outbound TCP connections. For the RTMP side, see how RTMP works and RTMP vs RTMPS.
SRT vs RTMP: where each one wins
Neither protocol is simply better; they're good at different jobs.
- SRT wins for contribution. Sending a feed from a remote venue, field crew or cellular link back to a production hub is where packet recovery pays off, as are broadcast chains feeding playout systems, decoders and media servers.
- SRT handles distance better. On intercontinental links with loss and jitter, a tuned latency buffer usually produces steadier results than TCP-based RTMP.
- RTMP wins on compatibility. Nearly every encoder, service and platform supports it, and setup is just a URL plus a key.
- RTMP is simpler to deploy. No UDP ports, latency tuning or passphrases to coordinate.
A practical rule: use SRT between systems you or a partner control, and RTMP or RTMPS for the final hop into public platforms.
Why YouTube, Twitch and most platforms still ask for RTMP
If SRT is so resilient, why do the major creator platforms keep documenting RTMP and RTMPS ingest?
First, compatibility: platforms want every streamer to connect, from phone apps to older hardware encoders, and RTMP is the protocol all of them speak. Second, most creators send from home to a nearby ingest server, where TCP performs well enough. Third, platforms have built years of authentication, key management and monitoring around RTMP.
That picture is shifting. Some platforms and many professional video services accept SRT or other newer ingest protocols. At the time of writing, though, a mainstream social or gaming platform will usually hand you an RTMP or RTMPS URL. The custom RTMP streaming guide explains how those destinations work.
Sending RTMP and SRT from the same cloud stream
Many setups need both protocols at once: RTMP for public platforms and SRT for a studio, a playout server or a partner's receiver. From a home encoder, that means two outputs and double the upload.
StreamHouse handles it in the cloud. Add YouTube, Twitch or Kick over RTMP or RTMPS, plus a custom SRT output pointed at your receiver, to the same stream. One broadcast reaches all of them, and extra destinations don't use extra stream slots.
For pre-recorded programming, upload your videos, which are prepared ahead of time to one consistent encode profile, then build a playlist and start or schedule it. The stream loops 24/7, reconnects automatically after network hiccups and keeps running with your computer switched off.
Frequently asked questions
Is SRT better than RTMP for streaming?
For long or unreliable network paths, usually yes, because SRT recovers lost packets without stalling the whole connection. Mainstream platforms often offer only RTMP or RTMPS, though, so the right choice depends on where your feed is going.
Does SRT have lower latency than RTMP?
It can. SRT's transport delay is roughly the latency buffer you set, which can be small on good networks. But viewers' total delay also depends on the platform's processing and playback, so switching protocols won't always feel faster.
Can OBS stream over SRT?
Yes. Enter an srt:// address as a custom server in OBS, with parameters such as mode, latency and passphrase included in the URL. The receiving server or service must support SRT and be set up to accept the connection.
Is SRT encrypted by default?
Only when you set a passphrase. With the same passphrase on both sides, SRT encrypts the feed using AES with 128-, 192- or 256-bit keys. Without one it travels unencrypted, so set one for feeds crossing the public internet.
