SRT vs RTSP vs RTMP vs WebRTC: Which Protocol Should You Use for Camera Streaming?

If you work with IP cameras, you have heard all four of these acronyms thrown around — often interchangeably, often incorrectly. "Just use RTSP." "RTMP is dead." "SRT is the future." "WebRTC for everything." The reality is that each protocol was designed for a different problem, and choosing the wrong one means you are fighting the architecture instead of building on it.

This article is a no-nonsense comparison of RTSP, RTMP, SRT, and WebRTC specifically for IP camera streaming — not live event production, not gaming, not video conferencing. We will cover what each protocol actually does at the wire level, where it excels, where it breaks, and when to use each one.

RTSP — The Camera's Native Language

RTSP (Real Time Streaming Protocol) is the protocol that virtually every IP camera speaks natively. Defined in RFC 2326 (1998) and updated in RFC 7826 (2016), it is a control protocol — meaning RTSP itself does not carry video data. It manages a session through text-based commands (DESCRIBE, SETUP, PLAY, TEARDOWN), while the actual video and audio are transported by RTP (Real-time Transport Protocol) on separate channels.

# Typical RTSP session flow
Client → Camera:  DESCRIBE rtsp://192.168.1.100:554/stream1 RTSP/1.0
Camera → Client:  200 OK (SDP body: codec=H.264, resolution=1920x1080)

Client → Camera:  SETUP rtsp://192.168.1.100:554/stream1/track1 RTSP/1.0
                  Transport: RTP/AVP;unicast;client_port=8000-8001
Camera → Client:  200 OK (server_port=9000-9001, session=12345678)

Client → Camera:  PLAY rtsp://192.168.1.100:554/stream1 RTSP/1.0
Camera → Client:  200 OK → RTP packets start flowing on UDP 9000

Transport modes

RTSP supports two transport modes for the underlying RTP data:

• UDP (default): RTP packets are sent as individual UDP datagrams. Lower latency, but packets can be lost or arrive out of order. Works well on local networks where packet loss is near zero.
• TCP interleaved: RTP packets are multiplexed over the same TCP connection as the RTSP control channel. More reliable, but TCP's head-of-line blocking can introduce jitter. Most RTSP clients use this mode when connecting over a WAN or through firewalls.

Where RTSP excels

• Universal camera support. Every Hikvision, Dahua, Axis, Hanwha, Reolink, and Amcrest camera speaks RTSP. It is the lingua franca of IP cameras.
• Local network performance. On a clean LAN, RTSP-over-UDP delivers video with minimal latency — often under 200 ms with a tuned client.
• Ecosystem depth. VLC, ffmpeg, GStreamer, OpenCV, every NVR, every VMS — they all consume RTSP. The tooling is mature and battle-tested.

Where RTSP breaks

• Not browser-compatible. No modern browser can play RTSP. It operates over raw TCP/UDP, which browsers do not expose to JavaScript.
• Fragile over the internet. RTSP was designed for trusted LANs. Over a WAN, UDP packets get dropped, firewalls block the dynamically negotiated RTP ports, and NAT traversal is a constant headache.
• No built-in encryption. Standard RTSP transmits everything — including credentials in the URL — in plaintext. RTSPS (RTSP over TLS) exists but camera support is inconsistent.
• Stateful sessions. RTSP maintains server-side session state. If the TCP connection drops, the session is lost and must be re-negotiated. Proxies and tunnels that recycle connections break RTSP silently.

RTMP — The Legacy Ingest Workhorse

RTMP (Real-Time Messaging Protocol) was developed by Macromedia (later Adobe) for Flash Player. It is a push-based protocol — a source pushes a stream to a server, rather than a client pulling it. RTMP runs over TCP port 1935 and multiplexes audio, video, and metadata in a chunked message format.

# Typical RTMP push (using FFmpeg to push a camera stream to YouTube)
ffmpeg -rtsp_transport tcp \
  -i rtsp://admin:password@192.168.1.100:554/stream1 \
  -c:v copy -c:a aac -f flv \
  rtmp://a.rtmp.youtube.com/live2/YOUR_STREAM_KEY

Where RTMP still matters

• Platform ingest. YouTube Live, Twitch, Facebook Live, and most streaming platforms accept RTMP as their primary ingest protocol. If you need to broadcast a camera feed to a public platform, RTMP is likely required.
• Mature tooling. FFmpeg, OBS Studio, Wirecast, and vMix all support RTMP output. The workflow for camera-to-platform streaming is well-documented.
• Reliable transport. Because RTMP runs over TCP, packets are guaranteed to arrive in order. No packet loss, no reordering — but at the cost of latency when the network degrades.

Where RTMP fails

• No browser playback. Flash Player was discontinued in December 2020. No modern browser can play RTMP natively. Playback requires transcoding to HLS or DASH on the server side.
• No camera supports it natively. IP cameras speak RTSP, not RTMP. To push a camera stream via RTMP, you need an intermediate server (FFmpeg, OBS, or a relay) to pull RTSP and re-push as RTMP.
• TCP-only = latency under stress. When the network has packet loss, TCP retransmits and waits. This causes buffering spikes that can reach several seconds. RTMP has no mechanism to skip or drop stale frames.
• No encryption by default. Standard RTMP is unencrypted. RTMPS (RTMP over TLS) exists but is not universally supported by ingest servers.

SRT — Built for Bad Networks

SRT (Secure Reliable Transport) was developed by Haivision and open-sourced in 2017. It was designed from the ground up to solve the specific problem that RTSP and RTMP handle poorly: reliable, low-latency video delivery over unpredictable networks — packet loss, jitter, fluctuating bandwidth, and long-distance routes.

SRT runs over UDP and adds its own reliability layer on top, rather than relying on TCP's retransmission. This is a critical architectural difference.

Key features

• ARQ (Automatic Repeat reQuest): SRT selectively retransmits only the packets that were lost, rather than stalling the entire stream like TCP does. This allows recovery from packet loss without the latency penalty of TCP retransmission.
• Configurable latency buffer: You set a latency target (e.g., 120 ms, 500 ms, 2000 ms). SRT uses this buffer window to recover lost packets. Higher latency = more time for retransmission = more resilience. Lower latency = less recovery time = more vulnerable to loss. You choose the tradeoff.
• AES-128/256 encryption: Built-in, mandatory-capable encryption. Unlike RTSP, where encryption is an afterthought (RTSPS), SRT was designed with encryption as a first-class feature. A single passphrase encrypts the entire stream.
• Connection bonding: SRT can bond multiple network paths (e.g., primary ethernet + cellular backup) and failover seamlessly — useful for mission-critical deployments.
• Caller/Listener/Rendezvous modes: SRT supports flexible connection initiation. In caller mode, the sender initiates the connection outbound — critical for cameras behind NAT or firewalls, since no port forwarding is needed on the sender side.

# Send an RTSP camera stream over SRT using FFmpeg
ffmpeg -rtsp_transport tcp \
  -i rtsp://admin:password@192.168.1.100:554/stream1 \
  -c:v copy -c:a copy -f mpegts \
  "srt://relay.example.com:9000?mode=caller&latency=500000&passphrase=mysecretkey"

# Receive and play on the other end
ffplay "srt://relay.example.com:9000?mode=listener"

Where SRT excels

• WAN transport. SRT was purpose-built for this. Sending video from a camera site to a remote server over the public internet — especially when the path is long, lossy, or unpredictable — is exactly what SRT optimizes for.
• Professional broadcast. SRT has been adopted by broadcast equipment manufacturers (Haivision, Matrox, Teradek, NewTek) and is increasingly used for remote production, contribution feeds, and point-to-point links replacing satellite.
• Security. AES encryption is built in, not bolted on. The stream is encrypted end-to-end with a passphrase — no TLS certificate infrastructure required.

Where SRT has limitations

• No browser support. Like RTSP, SRT runs over raw UDP and cannot be played in a browser. You need a conversion layer to deliver SRT content to web viewers.
• No camera supports it natively. IP cameras output RTSP, not SRT. You need an intermediate agent or encoder to pull RTSP from the camera and push SRT to the destination.
• Smaller ecosystem than RTSP. While FFmpeg, GStreamer, OBS, and VLC all support SRT, the ecosystem is younger than RTSP's. Some NVR and VMS software does not yet support SRT ingest.

WebRTC — Real-Time in the Browser

WebRTC (Web Real-Time Communication) is a collection of browser APIs and network protocols standardized by the W3C and IETF. Unlike the other three protocols, WebRTC was designed specifically to work inside web browsers — it is natively supported in Chrome, Firefox, Safari, and Edge with no plugins or extensions required.

How it works for camera streaming

A WebRTC camera stream does not connect directly from the browser to the camera. Instead, a server ingests the camera's RTSP stream, wraps the RTP video packets in DTLS-SRTP (mandatory encryption), and serves them to the browser via the RTCPeerConnection API. The browser decodes H.264 or VP8/VP9 natively and renders it in a <video> element.

ICE (Interactive Connectivity Establishment) handles network path discovery — the browser and server exchange "candidates" and find the optimal route. For camera streaming through a cloud relay, this typically resolves to a direct connection to the relay's public IP, so ICE succeeds reliably.

Where WebRTC excels

• Browser-native. The entire point. No VLC, no plugin, no app install. Open a URL, see the camera. Works on desktop, mobile, tablet — any device with a modern browser.
• Sub-second latency. WebRTC achieves 100–500 ms end-to-end latency even over the internet. It continuously streams RTP packets rather than buffering, and it can adapt bitrate in real-time based on network conditions.
• Mandatory encryption. All WebRTC media is encrypted via DTLS-SRTP. This is enforced by the browser — you cannot receive unencrypted WebRTC streams. For camera viewing, this means the video is always encrypted in transit.
• NAT traversal built in. ICE + STUN + TURN handle NAT traversal automatically. The viewer does not need port forwarding or a VPN — the browser handles connectivity.

Where WebRTC has limitations

• No camera supports it natively. Like RTMP and SRT, cameras do not speak WebRTC. A conversion server must bridge RTSP to WebRTC.
• Scaling is expensive. WebRTC is peer-to-peer by design. For one-to-many camera streaming (many viewers watching one camera), you need a Selective Forwarding Unit (SFU) or a media server. Each viewer connection consumes server resources.
• Codec constraints. Browsers support H.264 (Baseline/Main) and VP8/VP9 for WebRTC video. If the camera outputs H.265 (HEVC), the server must transcode to H.264 — a CPU-intensive operation.
• Not designed for recording. WebRTC is a real-time delivery protocol. It has no built-in recording, archival, or seek capability. You cannot "rewind" a WebRTC stream.

Latency Benchmarks

Latency is the most common decision factor, and the most commonly misquoted. Here are realistic numbers based on real-world camera streaming — not lab conditions.

Side-by-Side Comparison

When to Use Each Protocol

Use RTSP when...

• You are pulling a stream from a camera on the local network
• You are feeding video into an NVR, VMS, or processing pipeline (OpenCV, FFmpeg, GStreamer)
• You need the widest possible camera compatibility
• The viewer and camera are on the same LAN

Use RTMP when...

• You need to push a camera feed to YouTube Live, Twitch, Facebook Live, or a similar platform
• You are using OBS or a hardware encoder that outputs RTMP
• The destination server specifically requires RTMP ingest

Use SRT when...

• You are transporting video over the internet between two points (site-to-site, camera site to cloud)
• The network path is unreliable — packet loss, high jitter, long distance
• You need end-to-end encryption without TLS certificate infrastructure
• You are building contribution feeds for broadcast or remote production

Use WebRTC when...

• The viewer is a human with a browser (phone, laptop, tablet)
• You need sub-second latency for real-time monitoring
• You want to embed a live camera view in a webpage
• You need the viewer to access the stream without installing any software

How TheRelay Uses All Four

TheRelay's architecture is a concrete example of the multi-protocol pattern described above:

IP Camera (LAN)          Agent (LAN)            TheRelay Cloud           Viewer
┌──────────┐    RTSP    ┌──────────┐   SRT     ┌──────────────┐        ┌──────────┐
│ Hikvision├───────────►│ TheRelay ├──────────►│  Cloud Infra  ├───────►│ Browser  │
│ Dahua    │  pull on   │  Agent   │ encrypted │               │WebRTC │ VLC      │
│ Axis     │   LAN      │          │ outbound  │  Publishes:   │HLS    │ NVR      │
│ Reolink  │            │          │           │  - WebRTC     │RTSP   │ FFmpeg   │
│ Any cam  │            │          │           │  - HLS        │RTMP   │ YouTube  │
└──────────┘            └──────────┘           │  - RTSP       │SRT    │ OBS      │
                                               │  - RTMP       │       └──────────┘
                                               │  - SRT        │
                                               └──────────────┘

1. RTSP on the LAN. The agent pulls video from your cameras using RTSP — the protocol every camera supports. Camera credentials never leave your local network.
2. SRT over the WAN. The agent pushes video to TheRelay's cloud infrastructure via encrypted SRT. The connection is outbound (no port forwarding needed), AES-256 encrypted, and resilient to packet loss and jitter on the internet path.
3. All four protocols for delivery. The cloud publishes each camera stream simultaneously as WebRTC (browser, sub-second latency), HLS (maximum compatibility, ~5 s latency), RTSP (VLC, NVR, VMS integration), RTMP (push to YouTube/Twitch), and SRT (professional video tools).

A single camera registration gives you all five output endpoints. You do not choose one protocol — you get all of them, and your viewers or integrations use whichever one fits their use case.

Frequently Asked Questions

What is the lowest latency protocol for IP camera streaming?

WebRTC delivers the lowest practical latency for remote camera viewing — typically 100–500 ms end-to-end, even over the internet. On a local network, RTSP-over-UDP can match this (under 300 ms with tuned settings). Over a WAN connection, RTSP clients add several seconds of buffer for stability, while WebRTC maintains sub-second delivery. SRT achieves 200–1500 ms depending on your configured latency setting. RTMP typically lands at 1–5 seconds.

Should I use SRT or RTSP for remote camera access?

RTSP for local access, SRT for remote transport. RTSP is the native protocol of every IP camera and is universally supported by NVRs, VMS software, and media tools. For transporting camera streams over the internet, SRT is superior: it includes packet loss recovery (ARQ), jitter compensation, AES encryption, and automatic reconnection — features RTSP completely lacks. TheRelay uses this exact split: RTSP on the LAN to pull from cameras, SRT over the WAN to transport to the cloud.

Can I play SRT streams in a browser?

Not natively. SRT runs over raw UDP and is not accessible through browser APIs. To view an SRT stream in a browser, you need a server-side conversion layer that ingests SRT and re-publishes it as WebRTC (low latency) or HLS (maximum compatibility). FFmpeg, OBS, and relay platforms like TheRelay can perform this conversion.

Which protocol does TheRelay use?

All of them, at different stages. The agent pulls from cameras via RTSP. It transports to the cloud via encrypted SRT. The cloud publishes simultaneously as WebRTC (browser playback), HLS (device compatibility), RTSP (VMS/NVR integration), RTMP (platform ingest), and SRT (professional tools). One camera registration gives you all five outputs for $2/stream/month.

What is the difference between RTSP and RTMP?

RTSP is pull-based — a client sends DESCRIBE/SETUP/PLAY commands to request a stream from a server (camera). RTMP is push-based — a source pushes a stream to a server. RTSP supports UDP transport (lower latency); RTMP is TCP-only. RTSP is supported by virtually every IP camera; RTMP is not supported by any IP camera natively. RTSP is the standard for camera-to-client streaming; RTMP is the standard for client-to-platform ingest (YouTube, Twitch).