By Stan Reshetnyk, CTO, Trembit · Last updated 16 October 2026
WebRTC, HLS, SRT and RTMP are not rivals for one job. RTMP, SRT and WHIP carry a live stream from an encoder to your server. HLS, LL-HLS, DASH and WebRTC carry it from your server to viewers. CMAF is a packaging format that HLS and DASH share. “WebRTC vs HLS” is therefore a playback decision, and “RTMP vs SRT” is an ingest decision. This page compares these streaming protocols by role: transport, what each latency number measures, scale, browser support, encryption and firewall behavior.
Key takeaways
- Split every pipeline into two legs. RTMP, SRT and WHIP carry contribution, and browsers cannot play RTMP or SRT. HLS, LL-HLS, DASH and WebRTC carry playback. If you also need the on-demand side, see how to build a video streaming platform.
- Latency numbers measure different things. SRT’s is a configured network buffer, not glass-to-glass. Standard HLS often runs 20 to 30 seconds behind live, set mostly by segment length. Apple targets two seconds or less for LL-HLS; services publish best cases of three to five. AWS says WebRTC delivery can be under 300 ms.
- CMAF is not an alternative to HLS. It is a segment format that HLS and DASH both use, including their low-latency modes.
- Of the protocols in the first table, only WebRTC and WHIP are IETF Standards Track. HLS is an Informational RFC, LL-HLS lives in a separate draft, SRT’s draft has expired, and RTMP is an Adobe-published specification.
- Firewalls and DRM can rule a protocol out before latency does. SRT needs UDP, WebRTC falls back to TURN over TLS, HLS and DASH ride HTTPS, and multi-DRM in MSE players such as hls.js needs fMP4 segments.
Not an engineer? Read the key takeaways, which protocols go together and what Trembit has built. The rest is reference.
What does each streaming protocol do in a live pipeline?
A live pipeline has two network legs. The contribution leg carries one high-quality feed from a camera or encoder to your media server. The delivery leg carries it from that server to every viewer. The media server or packager sits between them, and that is where an RTMP or SRT feed gets repackaged as HLS or forwarded as WebRTC. CMAF is a third layer: the format of the media segments, not a leg of its own.
| Protocol | Job | Transport | Published latency, and what it measures | Standards status |
|---|---|---|---|---|
| RTMP | Contribution | TCP | 2 to 5 s (Wowza; scope not stated) | Adobe spec v1.0; Enhanced RTMP v1 (2025) |
| SRT | Contribution | UDP with retransmission | 120 ms default buffer in live mode, configurable 20 to 8,000 ms; network leg only (Haivision) | Expired individual Internet-Draft |
| WHIP | Contribution, WebRTC-native | HTTP signalling, WebRTC media | Same as WebRTC media | RFC 9725, Standards Track (2025) |
| HLS | Delivery | HTTP | Typically 25 to 30 s glass-to-glass (Mux); up to 30 s for traditional OTT (AWS) | RFC 8216, Informational (2017) |
| LL-HLS | Delivery | HTTP/2 or HTTP/3 | Apple target: 2 s or less. Services publish best cases: “as little as” 3 s (Cloudflare), “under 5 s” (AWS), “as low as” 5 s (Mux) | Independent Submission draft (rfc8216bis-22) |
| DASH / LL-DASH | Delivery | HTTP; LL-DASH adds chunked transfer | No published achieved figure found | ISO/IEC standard (MPEG-DASH) |
| WebRTC (+ WHEP) | Delivery, and two-way calls | SRTP, usually over UDP; TURN over TLS as fallback | “Can be under 300 ms” host to viewer (AWS IVS, vendor best case) | IETF Standards Track (2021); W3C Recommendation; WHEP still a draft |
| CMAF | Packaging format, not a protocol | n/a | n/a | ISO/IEC 23000-19 |
Sources: Wowza blog (4 May 2026); Haivision SRT documentation (v1.5.4); Mux and AWS IVS documentation (undated, read 16 October 2026); Cloudflare blog (25 September 2023); Apple WWDC19 and WWDC20 session descriptions. The figures come from different vendors, pipelines and dates, so they are not directly comparable.
SRT’s 120 ms is a buffer on one network hop. AWS’s 300 ms is a managed service’s best case from host to viewer. Before comparing two latency numbers, ask where each one starts and stops the clock.
Which protocol should carry the stream from the encoder to your server?
The ingest protocol follows from your encoder, your uplink and what the receiving platform accepts.
RTMP: is it still the default, and what does Enhanced RTMP change?
RTMP is the oldest protocol in the first table. The Enhanced RTMP specification dates its first public release to 2002 and describes it running “over a suitable transport protocol (such as TCP)”. It is unencrypted unless you use RTMPS, and since Adobe deprecated Flash Player in December 2020 no browser plays it (Wowza’s RTMP vs SRT comparison). RTMP now survives mainly as ingest: your server converts it to HLS or WebRTC.
Classic RTMP/FLV could not carry newer codecs. Enhanced RTMP v1 (revision v1-2025-01-22-r2) adds HEVC, VP9 and AV1, so confirm that both your encoder and your server implement it. RTMP persists because platforms and encoders still accept it.
SRT: what does it add over RTMP, and why can’t a browser play it?
SRT (Secure Reliable Transport) is “a user-level protocol over User Datagram Protocol”, per its Internet-Draft. It adds ARQ retransmission of lost packets, optional AES encryption with 128-, 192- or 256-bit keys (off until a passphrase is set, per Haivision’s socket options), and caller-listener or rendezvous connection modes (§4.3). AWS describes it as “designed to improve streaming over unreliable networks”.
What “SRT latency” means. Haivision’s latency documentation is explicit: “In SRT, however, “latency” is defined as only the delay introduced by sending over the network.” It is a receive buffer you configure, from 20 to 8,000 ms, and Haivision’s suggested rule of thumb is four times the round-trip time on a network with 0.1 to 0.2% loss. The library default is 120 ms in live mode. Capture, encoding, decoding and display all sit outside it.
An 80 ms round trip means a 320 ms buffer for that hop. Wowza describes SRT as achieving “approximately one second of glass-to-glass latency”. The two figures measure different spans, so they don’t compare directly.
As Wowza puts it, neither SRT nor RTMP “plays natively in browsers”, so a server converts the feed. The IETF datatracker lists draft-sharabayko-srt-01 (September 2021) as an expired individual draft, still “In ISE Review” as of 16 October 2026; the working reference is Haivision’s open-source library. Managed ingest supports it: AWS IVS accepts SRT, and Cloudflare Stream Live takes live video “over either RTMPS or SRT”.
WHIP: where does WebRTC-native ingest fit?
WHIP, RFC 9725 (Standards Track, March 2025), standardizes how an encoder publishes WebRTC to a server over HTTP. Use it when you control the encoders and want one WebRTC path end to end, with no RTMP-to-WebRTC conversion on the server.
RTSP: why is it only a camera-side protocol?
IP cameras commonly expose their video over RTSP, so RTSP appears upstream of your media server, between camera and server, never toward viewers. A bridge on the server converts it to WebRTC or HLS for playback.
Which protocol should carry the stream from your server to viewers?
Playback is where audience size, CDNs, browsers and DRM enter the decision. HLS and DASH publish files a CDN can cache. WebRTC holds a live connection to every viewer.
HLS: why does standard HLS sit 20 to 30 seconds behind live?
HLS publishes a playlist of short media segments over HTTP, and the player fetches them in order. Much of the delay comes from one rule in RFC 8216 §6.3.3:
“If the EXT-X-ENDLIST tag is not present and the client intends to play the media normally, the client SHOULD NOT choose a segment that starts less than three target durations from the end of the Playlist file.”
The arithmetic is ours, not a measurement, and it scales with segment length. RFC 8216 §6.2.1 says “A typical target duration is 10 seconds”, which puts the player about 30 seconds behind the newest segment. The newer draft’s §6.2.1 says “A typical Target Duration is 6 seconds”, which gives 18. Shorter segments shrink it further, at the cost of more requests. Encoding, CDN propagation and the player buffer come on top.
Published figures agree. Mux puts standard HLS at “greater than 20 seconds and typically about 25 to 30 seconds” glass-to-glass, and AWS IVS says that for a traditional OTT stream, “latency may be as high as 30 seconds”. The return on that delay is scale: segments are ordinary HTTP objects that any CDN can cache.
LL-HLS: what changes, and what latency does it really deliver?
Low-Latency HLS is not in RFC 8216. It lives in draft-pantos-hls-rfc8216bis, which describes protocol version 13 and would obsolete RFC 8216 “if approved”. As of 16 October 2026, revision 22 (dated 1 May 2026, expiring 2 November 2026) is an Apple-authored Independent Submission draft with intended status Informational, and the datatracker shows it sent to the RFC Editor.
Four mechanisms move the player toward the live edge:
- Partial segments (EXT-X-PART, §4.4.4.9), with the Part Target Duration declared in EXT-X-PART-INF (§4.4.3.7). The player fetches parts as they are produced.
- Preload hints (EXT-X-PRELOAD-HINT, §4.4.5.3). The player requests the next part before it exists.
- Blocking Playlist Reload (§6.2.5.2). The server “MUST defer responding to the request until the Playlist contains the Partial Segment with Part Index N and with a Media Sequence Number of M or later”. No polling.
- A closer start point (§6.3.3 and §4.4.3.8). PART-HOLD-BACK “MUST be at least twice the Part Target Duration” and “SHOULD be at least three times” it.
So the part duration sets the floor. With one-second parts (an example, not a recommendation), the recommended hold-back alone is three seconds, before encoding, CDN and decoding.
What it really delivers. Apple’s WWDC19 session says “latencies of less than two seconds are now achievable over public networks at scale”, and its WWDC20 session describes “a stream delay of two seconds or less”. Services publish higher numbers for their full paths. Cloudflare’s 2023 beta announcement says “as little as three seconds”, counting client-side buffering. AWS IVS says “under 5 seconds”, and Mux says “as low as 5 seconds glass-to-glass”. Apple states a design target; services state what their own chain delivers, and yours depends on your encoder, CDN and player.
What it requires. The draft’s low-latency server profile (Appendix B.1) serves playlists and segments “via HTTP/2 [RFC9113] or HTTP/3 [RFC9114]” and expects that “CDNs and other proxy caches recognize blocking requests”. At WWDC20, Apple said it had replaced HTTP/2 Push with blocking preload hints, though CDNs “do still need to support HTTP/2”. Players need LL-HLS support too (Mux lists minimum versions).
DASH and low-latency DASH: how do they differ from HLS?
MPEG-DASH, an ISO/IEC standard, uses the same model as HLS, a manifest plus HTTP segments, with an MPD (Media Presentation Description) in place of an M3U8 playlist. Browsers play it through a JavaScript player such as dash.js, the DASH Industry Forum’s reference client, which targets browsers with Media Source Extensions and Encrypted Media Extensions.
Low-latency DASH changes the transport, not the model. The dash.js low-latency guide requires that “The server must support HTTP 1.1 Chunked transfer encoding” and that “The segments must contain multiple CMAF chunks”. The MPD’s availabilityTimeOffset and a ServiceDescription latency target steer the player; the guide’s example targets 4,000 ms within a 2,000 to 6,000 ms window. That is a configuration, not a measured result. We found no primary source for an achieved LL-DASH figure, so we quote none.
WebRTC and WHEP: what does sub-second playback cost?
WebRTC sends media continuously, with no segments and so no segment-duration floor. ICE sets up the connection, and RFC 8835 requires browser endpoints to run “a full ICE implementation, not ICE-Lite”. Keys are negotiated with DTLS-SRTP (RFC 8827). The AWS IVS Real-Time guide says its latency “can be under 300 milliseconds from host to viewer”, a vendor claim for its own service.
The cost is architectural. Each viewer is a live, stateful connection that a server must forward packets to, so scale comes from a media-server (SFU) tier, not from a CDN caching files. AWS IVS Real-Time lists support for “audiences beyond 25,000 viewers”. Building and operating that tier is the core of custom WebRTC development for broadcast products.
WHEP, WHIP’s playback counterpart, is still an Internet-Draft as of 16 October 2026: draft-ietf-wish-whep-05, in Area Director evaluation, intended as a Proposed Standard. Media over QUIC is a separate transport effort, covered in our MoQ vs WebRTC comparison.
Is CMAF an alternative to HLS?
No. CMAF (ISO/IEC 23000-19, Common Media Application Format) defines a segment format based on fragmented MP4. HLS and DASH are the manifest-and-delivery layers that point to those segments. The HLS draft notes that “a CMAF Segment meets these requirements” for its fMP4 segments, Apple’s WWDC20 session lists “fMP4 CMAF” among LL-HLS features, and LL-DASH requires CMAF chunks.
“CMAF vs HLS” therefore compares a packaging layer with a delivery protocol. The useful question is which segment format sits under your HLS, MPEG-2 TS or fMP4/CMAF, because in MSE-based players it decides multi-DRM: hls.js supports FairPlay, PlayReady and Widevine “with fmp4 segments”, not with TS. One set of CMAF segments can, in principle, serve both an M3U8 playlist and an MPD. Check that the encryption scheme suits both players, since the HLS draft encrypts fMP4 with the “‘cbcs’ scheme of Common Encryption”.
How do browser support, encryption, DRM and firewalls differ?
| Protocol | Plays in a browser? | Scale model | Encryption / DRM | Firewall and NAT |
|---|---|---|---|---|
| RTMP | No; Flash playback ended December 2020 (Wowza) | One connection per contribution feed | None by default; RTMPS adds TLS (Wowza) | TCP, port 1935 for standard RTMP (Wowza) |
| SRT | No native playback (Wowza) | One connection per contribution feed | Optional AES-128, -192 or -256; off unless a passphrase is set (Haivision) | UDP; the firewall must pass the chosen UDP port (Wowza) |
| HLS / LL-HLS | Native in Safari; most other browsers use an MSE player such as hls.js | CDN-cacheable HTTP objects | Segment encryption: AES-128 or SAMPLE-AES (RFC 8216 §4.3.2.4). DRM: FairPlay, PlayReady, Widevine with fMP4 (hls.js) | HTTPS over TCP; the LL-HLS profile also allows HTTP/3 |
| DASH / LL-DASH | Through an MSE/EME player such as dash.js | Same CDN model; LL-DASH needs chunked transfer end to end | DRM through Encrypted Media Extensions (dash.js) | HTTPS |
| WebRTC | Built into all modern browsers (webrtc.org) | A stateful connection per viewer through an SFU tier | SRTP mandatory, keyed with DTLS-SRTP (RFC 8827) | Prefers UDP; ICE-TCP and TURN over TLS mandatory to implement (RFC 8835) |
The WebRTC row rests on two sentences. RFC 8827 §6.5 says “Media traffic MUST NOT be sent over plain (unencrypted) RTP or RTCP”, so a WebRTC stream is always encrypted in transit. RFC 8835 §3.4 makes ICE-TCP and TURN over TLS mandatory “to deal with firewalls that block all UDP traffic”.
If a network blocks outbound UDP, SRT ingest stops. HLS and DASH pass as ordinary web traffic. WebRTC can reach a server with a public address over ICE-TCP, but TURN over TLS is the dependable path, and you run those servers: the standard requires browsers to support it, not to provide it.
If you need DRM on a WebRTC stream, ask your vendor what it adds beyond transport encryption.
Which protocols go together, and how do you choose for each leg?
| Pairing | Contribution | What the server does | Delivery |
|---|---|---|---|
| Broadcast-style | RTMP or SRT | Transcodes and packages segments | HLS or LL-HLS through a CDN |
| WebRTC end to end | WHIP | Forwards through a WebRTC media server | WebRTC |
| One feed, two paths | One contribution feed | Fans out to an SFU and a packager | WebRTC for interactive viewers, HLS for everyone else |
Choose each leg by what rules options out, not by a latency ranking. Our engineering judgment:
- Ingest. If the platform only accepts RTMP(S), use RTMP. On a lossy or long-haul uplink, or with broadcast contribution gear, use SRT if the receiver accepts it and the path passes UDP. If you control the encoders and want WebRTC end to end, use WHIP.
- Playback. If you need DRM, use HLS or DASH with fMP4/CMAF segments. If viewers sit on UDP-blocked networks, use an HTTP-based protocol, or WebRTC with TURN over TLS provisioned. If viewers act on the stream as it happens (bidding, answering, trading), use WebRTC.
How much delay your product can tolerate, and what each latency level costs to run, is a separate decision. We cover it in our guide to when WebRTC is mandatory and when it is overkill.
If you are choosing ingest and delivery paths for a live product, that is the work our live streaming team does. Book a 30-minute call to pressure-test your plan.
What has Trembit built across these protocols?
Our published case studies cover WebRTC delivery, HLS alongside WebRTC, RTSP bridging and Wowza adaptive-bitrate pipelines. We have no published case study of SRT contribution or LL-HLS delivery, so those sections rest on the specifications and vendor documentation cited, not on our own delivery.
- One feed, two playback protocols. For a defense client streaming from drones, we built a GStreamer pipeline on Raspberry Pi hardware that serves WebRTC for the lowest-latency path, at sub-second glass-to-glass, and an AES-encrypted HLS path, from one encoding pipeline. The encode runs once; each path carries its own encryption (DTLS/SRTP for WebRTC, AES for HLS). As the case study puts it, “Running WebRTC and HLS simultaneously on Raspberry Pi means sharing a single encoder output.”
- Protocol bridges into WebRTC. For a US government agency, we built the RTSP-to-WebRTC bridge on Janus that brings live IP-camera feeds into conference sessions. It took dedicated work in the Janus RTSP plugin, because RTSP camera streams and WebRTC browser sessions “operate on fundamentally different protocols, codecs, and timing models.” A 2022 write-up shows an RTMP drone feed converted to WebRTC, as an example rather than current guidance.
- Sub-second broadcast. For Bullpit, a live streaming platform for financial-market traders and analysts, we integrated Millicast as the WebRTC broadcast layer, delivering sub-second video to thousands of concurrent viewers.
- Adaptive bitrate delivery. For Livebazaar, a live video shopping platform, we deployed Wowza Streaming Engine with adaptive bitrate for variable network conditions.
Frequently asked questions
Is SRT better than RTMP? They solve different problems. SRT adds retransmission and optional AES over UDP, which helps on lossy or long-distance uplinks. RTMP runs over TCP, so it passes networks that block UDP, though its port 1935 is sometimes filtered. Check what your platform accepts.
Can a browser play SRT or RTMP? No. Your media server converts the feed to HLS, DASH or WebRTC for viewers.
Is CMAF the same as HLS? No. CMAF is a segment format; HLS is a playlist-and-delivery protocol that can carry CMAF segments, and so can DASH. See Is CMAF an alternative to HLS?
How low can LL-HLS go? Apple’s stated target is two seconds or less. Managed services publish best cases of three to five seconds for their full paths.
Does WebRTC need a media server to reach a large audience? Yes. Each viewer holds a live connection, so a large audience needs a media-server (SFU) tier rather than a file CDN. Our guide to SFU, MCU and P2P architectures covers the options.
Do I need WHIP if my encoder already sends RTMP? Not necessarily. RTMP into a server that converts to WebRTC works today. WHIP removes that conversion when you control the encoders. During a migration, keep RTMP ingest available so existing broadcasters keep working. Our WHIP and WHEP explainer covers how that handshake works.
Weighing ingest and playback protocols for a live product? Book a free 30-minute call with our WebRTC consulting team. Bring your current ingest and playback path (encoders, protocols, where viewers get stuck) and the decision you’re weighing. We’ll pressure-test it with you. No deck, no pitch.
