| Protocol | Typical latency | Use case |
|---|
| WebRTC | 100-500 ms | Video calls, real-time interaction |
| SRT | 500ms-2s | Broadcast contribution |
| RTMP | 2-5s | OBS to Twitch/YouTube |
| HLS Low Latency | 2-3s | Live broadcast |
| HLS Standard | 6-30s | VOD-like live streaming |
| DASH Low Latency | 2-3s | Live broadcast |
WebRTC is dramatically faster than other options. RTMP is the legacy default. HLS is the consumer streaming default but slower.
For sub-second latency: WebRTC is the only option. For everything else: RTMP or HLS works.
WebRTC is right for:
- Video calls (Zoom, Google Meet, Teams): low latency essential
- Live customer support: real-time interaction
- Interactive streams: viewer participation
- Game streaming with chat lag matching: sub-second feedback
- Telemedicine: real-time response
- Watch parties (synchronized viewing): matching viewer timing
For workflows where 2-second latency is unacceptable: WebRTC.
RTMP is right for:
- OBS Studio to Twitch: industry default
- Standard live streaming: viewer doesn't notice 2-3s latency
- Broadcast contribution: studio to playout
- Webinar broadcasting: presenter to audience
- Educational streaming: latency doesn't matter for one-way
For most "live but not real-time" streaming: RTMP works fine.
For OBS streaming context, see Twitch and OBS Bitrate Settings.
WebRTC:
- Peer-to-peer (or via SFU server)
- UDP-based for low latency
- Built into browsers (no plugins)
- Encrypted by default (DTLS)
- Adaptive bitrate per connection
RTMP:
- Client-server
- TCP-based for reliability
- Originally Flash-based; now FFmpeg/OBS
- Optional encryption (RTMPS)
- Single bitrate (re-encoded server-side for adaptive HLS)
WebRTC's distributed architecture suits real-time. RTMP's centralized model suits one-to-many broadcast.
For browser-to-browser:
const peerConnection = new RTCPeerConnection({
iceServers: [{ urls: "stun:stun.l.google.com:19302" }],
});
// Add local stream
const stream = await navigator.mediaDevices.getUserMedia({
video: true,
audio: true,
});
stream.getTracks().forEach((track) => peerConnection.addTrack(track, stream));
// Send offer to peer
const offer = await peerConnection.createOffer();
await peerConnection.setLocalDescription(offer);
// Signal offer.sdp to remote peer
// On receiving answer
await peerConnection.setRemoteDescription(remoteAnswer);
The setup is more involved than RTMP but produces real-time peer-to-peer streaming.
For production deployment: WebRTC SFU (Selective Forwarding Unit) servers like LiveKit, Daily, Janus, mediasoup.
For OBS to Twitch:
- OBS: Settings > Stream
- Service: Twitch
- Server: Auto (Recommended)
- Stream Key: from Twitch dashboard
- Click "Start Streaming"
OBS encodes locally and pushes via RTMP to Twitch's ingest server. Twitch transcodes for adaptive HLS delivery to viewers.
For RTMP from FFmpeg:
ffmpeg -i source.mp4 \
-c:v libx264 -preset veryfast -b:v 6000k \
-c:a aac -b:a 192k \
-f flv rtmp://live.twitch.tv/app/STREAM_KEY
For RTMP server, use Nginx with rtmp-module:
rtmp {
server {
listen 1935;
application live {
live on;
record off;
}
}
}
For OBS bitrate settings, see Twitch and OBS Bitrate Settings.
| Codec | WebRTC | RTMP | HLS |
|---|
| H.264 | Yes | Yes | Yes |
| H.265 (HEVC) | Limited | Yes | Yes |
| VP8 | Yes (default) | Limited | Limited |
| VP9 | Yes | Limited | Yes |
| AV1 | Yes (newer) | Limited | Yes |
| Opus audio | Yes (default) | Limited | Limited |
| AAC audio | Limited | Yes | Yes |
WebRTC defaults to VP8/Opus. RTMP defaults to H.264/AAC. For cross-platform: H.264/AAC works in both.
For underlying codec context, see HEVC to H.264 for Premiere.
For 1080p 30fps stream:
| Protocol | Upload bandwidth |
|---|
| WebRTC | 2-4 Mbps |
| RTMP | 4-8 Mbps |
| HLS | 4-8 Mbps |
| 4K WebRTC | 6-10 Mbps |
| 4K RTMP | 15-30 Mbps |
WebRTC is more efficient (P2P, adaptive bitrate). RTMP needs higher bitrate for similar quality.
For Twitch-specific bandwidth, see Twitch and OBS Bitrate Settings.
| Protocol | One-to-many at scale |
|---|
| WebRTC P2P | Limited (browser memory, network) |
| WebRTC SFU | Hundreds to thousands |
| RTMP via CDN | Millions (with HLS distribution) |
| HLS | Millions (CDN-friendly) |
For massive scale (Twitch millions of viewers): RTMP ingest + HLS distribution. WebRTC SFU for hundreds; RTMP-to-HLS for millions.
For broader streaming infrastructure, see Cloudflare Stream vs Mux vs Bunny.
WebRTC P2P fails with NAT: STUN/TURN servers needed. Use Google STUN, Cloudflare TURN, or run own servers.
RTMP latency too high: protocol-inherent. Switch to WebRTC for sub-second.
WebRTC quality drops on poor network: protocol adapts; some loss visible. RTMP doesn't adapt as well.
Browser doesn't support WebRTC codec: try different codec, or use FFmpeg-based streaming (RTMP via OBS).
RTMP rejected by ingest: codec or bitrate mismatch. Check platform spec sheet.
For broader streaming context, see DASH vs HLS Streaming.
For interactive streams (chat-driven): yes. For one-way broadcast: RTMP is fine and simpler.
No. RTMP's design has 2-3s buffer. For sub-second: WebRTC or specialized SRT.
Deprecated with Flash. Don't build new applications on RTMFP.
Twitch and YouTube continue accepting RTMP. They're transitioning to RTMP Enhanced (newer codecs) and RTMPS (encrypted), but the protocol remains in use.
HLS is for delivery (viewer side). RTMP is for ingest (broadcaster side). They serve different ends of the streaming pipeline.
Yes. WebRTC supports peer-to-peer over local networks (LAN). Useful for in-room broadcasting.
For streaming protocol choice in 2026: WebRTC for real-time interactive (video calls, watch parties), RTMP for traditional one-way broadcast (OBS to Twitch), HLS for distribution to millions of viewers. Each serves different latency requirements. Our video compressor handles source preparation regardless of streaming protocol.
