RTMP vs SRT vs WebRTC: Which Protocol for Live Streaming?

A live stream travels in two stages. First, your encoder sends the video to a server: this is ingest or contribution. Then the server delivers it to viewers: this is distribution. Different protocols suit each stage. HLS and DASH dominate distribution to large audiences. For ingest, the three names you will meet are RTMP, SRT and WebRTC.

This guide compares them on latency, reliability, compatibility and complexity, so you can choose the right one for your setup.

The quick answer

• RTMP (or RTMPS): use it when you stream to YouTube, Twitch, Facebook, LinkedIn or most platforms. It is supported everywhere.
• SRT: use it when the network between you and the server is unreliable (public internet over long distances, mobile, venue Wi-Fi) or when you control both ends, such as a remote production feed to a studio.
• WebRTC (with WHIP): use it for browser-based broadcasting, real-time interaction and sub-second latency workflows.

RTMP: the old reliable

The Real-Time Messaging Protocol was created by Macromedia for Flash and later maintained by Adobe. Flash is long gone, but RTMP survived as the standard way to send a stream from an encoder like OBS to a platform.

How it works: RTMP runs over TCP, usually on port 1935. RTMPS wraps it in TLS on port 443 for encryption. The encoder connects to an ingest URL with a stream key and pushes a continuous stream of H.264 video and AAC audio.

Strengths

• Supported by every major platform and nearly every encoder, hardware and software.
• Simple: an ingest URL and a stream key.
• Low latency for ingest, typically under a second or two.
• Enhanced RTMP, an industry update adopted from 2023 onwards, adds HEVC, AV1 and VP9 support in OBS and some platforms.

Weaknesses

• Because it runs over TCP, packet loss causes retransmissions and the stream backs up. On a lossy connection, the encoder drops frames or the connection resets.
• Classic RTMP supports only a limited set of codecs.
• Not designed for today’s variable mobile networks.
• Plain RTMP is unencrypted. Use RTMPS where available.

SRT: built for bad networks

Secure Reliable Transport was developed by Haivision and released as open source in 2017. The SRT Alliance now includes hundreds of companies. It was designed to send broadcast-quality video over the unpredictable public internet.

How it works: SRT runs over UDP. It adds its own recovery layer: when packets are lost, the receiver asks for them again (ARQ), but only within a latency window you configure, for example 120 ms to a few seconds. If a packet cannot be recovered within the window, SRT moves on rather than stalling everything. It also encrypts the stream with AES and handles firewalls through caller, listener and rendezvous modes.

Strengths

• Excellent on lossy or high-latency connections. It keeps going where RTMP falls over.
• Tunable latency: trade delay for resilience depending on the network.
• Codec-agnostic: it carries MPEG-TS, so H.264, HEVC and others work.
• Built-in AES encryption.
• Open source and widely supported by professional encoders, OBS, vMix, FFmpeg and media servers.

Weaknesses

• Platform support is growing but not universal. Many social platforms still prefer RTMP.
• Needs a sensible latency setting. Too low and it cannot recover losses. A common rule is at least 3 to 4 times the round-trip time to the server.
• Not playable in browsers. It is a contribution protocol only.

Typical uses: remote contributions to TV studios, sending feeds between cloud regions, streaming from events over venue internet, backpack and mobile production, and ingest into your own media servers.

WebRTC: real time, in the browser

Web Real-Time Communication is a set of browser APIs and protocols built for video calls. It is supported by every modern browser without plug-ins.

How it works: WebRTC uses UDP with RTP/SRTP for media, DTLS for key exchange, and ICE/STUN/TURN to connect through NATs and firewalls. It adapts bitrate continuously to network conditions and prefers dropping or concealing lost data over waiting for it, which keeps latency extremely low.

For streaming, two standards made WebRTC practical:

• WHIP (WebRTC-HTTP Ingestion Protocol): lets encoders such as OBS publish a WebRTC stream to a server with a simple HTTP request.
• WHEP (WebRTC-HTTP Egress Protocol): lets players pull a WebRTC stream in the same way.

Strengths

• Sub-second latency end to end.
• Works directly from a browser, so guests can join a show with no software.
• Adaptive to network changes in real time.
• Encrypted by design.

Weaknesses

• Scaling to large audiences needs specialised infrastructure (SFUs and WebRTC CDNs), which costs more than HTTP streaming.
• Quality can dip aggressively on poor networks because it prioritises latency.
• Codec choices depend on browsers (commonly H.264, VP8, VP9, AV1 for video and Opus for audio).
• More moving parts: signalling, TURN servers and media servers.

Typical uses: interactive shows, remote guests, auctions, betting, live shopping, classrooms, and sub-second distribution to modest audiences. See low-latency streaming explained for how WebRTC compares with LL-HLS for viewers.

Side-by-side comparison

What about the delivery side?

None of these three is usually what viewers receive at scale. After ingest, your platform or media server transcodes the stream and delivers it as:

• HLS or DASH for large audiences, with 6 to 30 seconds of latency, or 2 to 5 seconds with LL-HLS and LL-DASH. See HLS vs DASH.
• WebRTC for real-time audiences.

A common modern pipeline is: SRT or RTMP in → transcoding → LL-HLS out through a CDN, with WebRTC for any interactive guests.

Practical setup tips

RTMP in OBS: Settings → Stream → choose your service or “Custom”, paste the server URL and stream key. Use RTMPS if offered. Set keyframe interval to 2 seconds and CBR as recommended by the platform. Check upload headroom with our streaming bandwidth calculator and read how much upload speed you need.

SRT in OBS: choose “Custom” and enter an srt:// URL provided by your server, for example srt://ingest.example.com:9000?streamid=...&latency=2000000 (OBS takes latency in microseconds in the URL). Set the latency based on your round-trip time and loss, and test with a long private stream.

WebRTC with WHIP in OBS: recent OBS versions include a WHIP output option. Enter the WHIP endpoint and bearer token from your provider. Keep bitrates moderate, since WebRTC adapts aggressively on weak networks.

Choosing, by scenario

• Streaming games or talks from home to Twitch or YouTube: RTMP(S). Simple and universal.
• Streaming a conference from venue Wi-Fi to your own platform: SRT, with a generous latency window, plus a backup 5G connection.
• Sending a remote camera feed across continents to a studio: SRT.
• Running a live show with remote guests joining from browsers: WebRTC for guests, RTMP or SRT from your production software to the platform.
• Live auction where bids must match the picture: WebRTC end to end.

Security considerations for each protocol

Streams can be hijacked or intercepted if ingest is not secured.

• RTMP: plain RTMP sends the stream key and video unencrypted. Always prefer RTMPS where the platform supports it, and treat stream keys like passwords. Rotate them if they leak.
• SRT: enable AES encryption with a strong passphrase, and use streamid values that your server validates, so random senders cannot publish to your endpoint.
• WebRTC: media is always encrypted with DTLS-SRTP. Protect WHIP endpoints with bearer tokens and short-lived credentials.

For all three, restrict which IP addresses can publish if your encoders have fixed locations, and monitor for unexpected publishers.

Redundancy

For important events, send two streams: a primary and a backup, ideally over different connections and to different ingest points. Most platforms and media servers accept a backup ingest URL and fail over automatically. SRT and RTMP both work well for this. Test the failover before the event, not during it.

Troubleshooting each protocol

RTMP keeps disconnecting. Check the upload first with a sustained test, not a quick speed test. Then check the stream key and whether you are using rtmp:// where the platform expects rtmps://. Some networks block port 1935, so RTMPS on port 443 often fixes corporate or hotel connections. Our guide to upload speed for live streaming shows how to test properly.

SRT connects but the picture breaks up. The latency window is probably too small for the network. Increase it step by step, for example from 500 ms to 1,500 ms, until artefacts stop. Also confirm both ends use the same passphrase and key length.

WebRTC works for some guests but not others. This is almost always NAT traversal. Guests on strict corporate or mobile networks need a TURN server to relay media. Make sure your platform provides one and that it supports TCP and TLS fallbacks.

All three look soft. That is an encoding question, not a protocol one. Check bitrate, resolution and preset against our encoding settings guide.

Summary

RTMP is the universal, simple choice for sending streams to platforms, but it struggles on unreliable networks. SRT adds packet recovery, encryption and tunable latency, making it the professional choice for contribution over the public internet. WebRTC brings sub-second, browser-native video and is ideal for interactive production, though it is harder to scale for large audiences. Most streams use one of these for ingest and HLS or DASH for delivery. Pick the ingest protocol that fits your network and your platform, not the one with the lowest number on a chart.