Protocol Comparison Matrix: 8 Streaming Protocols × 12 Criteria

Why This Matters

If you are picking a streaming protocol in 2026, you are not picking one protocol — you are picking a stack, almost always with a different protocol for contribution than for delivery, and frequently with two delivery protocols layered for two different audience tiers (the hybrid stacks article explains the architecture; this article gives you the data behind the choice). Marketing pages from vendors will tell you their preferred protocol "wins" — but most of those comparisons cherry-pick one or two criteria and quietly ignore the eight or nine where their pick is mediocre. This article is the canonical Fora Soft reference for the actual numbers: glass-to-glass latency at scale, browser support as of May 2026, CDN compatibility, codec restrictions, packaging overhead, DRM story, contribution vs delivery role, and three forms of cost. If a vendor's claim does not match the cells here, the vendor is summarising a benchmark on their own infrastructure — not the protocol itself.

How To Read This Matrix

Each cell in the matrix carries a single piece of information about a single protocol against a single criterion. The matrix is not a leaderboard. Reading it well requires three habits.

Latency numbers are ranges, not points. A protocol's glass-to-glass latency depends on the encoder, the segment size, the network, the player buffer policy, and the CDN's segment caching strategy. When a row says "2–4 seconds", that is the well-tuned production range — not a best-case lab number and not a worst-case incident. Vendor marketing pages routinely quote the lab number ("HLS at 200 ms!") and quietly leave off the CDN tier and the player tuning. Treat any single-point latency claim with suspicion.

Browser support is a feature flag, not a binary. A row that says "Safari: HLS native, others: MSE-based" means every major browser plays HLS — but Safari uses the operating system's HLS stack, and Chrome, Firefox, and Edge use a JavaScript player (typically hls.js) that decodes through MSE. That difference matters in production: native playback has no garbage collection pauses, but the MSE path lets you instrument every byte. A binary "yes/no" hides this; the matrix below uses words.

Cost is always at least three numbers. Per-viewer egress cost is what most articles quote ("LL-HLS costs $X per viewer-hour"). It is the smallest of the three. Infrastructure cost — the origin, the packager, the SFU, the DRM key server — dominates at low scale and disappears at high scale. Engineering cost — the team you need to keep the stack running — is the silent killer of "low-cost" protocols that turn out to need three engineers full-time. The matrix breaks cost into all three.

Figure 1. The 8 × 12 matrix is a tool, not a ranking. Each cell hides nuance; the prose below the table is where the real story lives.

The Eight Protocols

Before the matrix itself, here is one short paragraph each on what every protocol is, in plain language. If a term feels new, the protocol family-tree article lays out the lineage in detail; the deep-dive articles linked below each name carry the full specification walkthrough.

HLS — HTTP Live Streaming. The Apple-originated HTTP-based delivery protocol now standardised as IETF RFC 8216 (August 2017). A small text file called an M3U8 playlist points to a sequence of two- to six-second video segments, each fetched over plain HTTP. HLS plays natively on every Apple device and through JavaScript players (hls.js) on every other browser. The standard latency floor is 6–15 seconds; the floor is what makes LL-HLS necessary.

LL-HLS — Low-Latency HTTP Live Streaming. Apple's 2019 extension to HLS that breaks each segment into parts (typically 200–300 millisecond sub-segments) and adds preload hints and blocking playlist reloads so the player can fetch the next part before the encoder has finished writing it. The controlling document is Apple's HLS Authoring Specification for Apple Devices, not a separate IETF RFC — Apple removed HTTP/2 server push from the spec in the 2023 revision, contradicting many older articles that describe push as required. Production glass-to-glass latency: 2–5 seconds.

MPEG-DASH — Dynamic Adaptive Streaming over HTTP. The ISO/IEC alternative to HLS, defined in ISO/IEC 23009-1:2022. A larger XML file called the MPD (Media Presentation Description) points to segments structured into periods, adaptation sets, and representations. DASH is codec-agnostic by design and the de facto delivery format for non-Apple platforms — but Apple devices cannot play DASH natively. Standard latency: 6–30 seconds.

LL-DASH — Low-Latency MPEG-DASH. DASH with CMAF chunked-transfer encoding plus the availabilityTimeOffset and segmentDuration tuning from the DASH Industry Forum's low-latency guidelines. Each segment is sent as it is being produced, byte-by-byte, over HTTP chunked encoding rather than wait-until-complete. Production glass-to-glass latency: 2–4 seconds. Often paired with LL-HLS off the same CMAF source so the same packaged bytes serve both ecosystems.

WebRTC — Web Real-Time Communications. The browser-native peer-to-peer real-time stack defined by the W3C and the IETF RFC 8825–8866 family. Transport is UDP via RTP, encryption is DTLS-SRTP, and signalling is whatever you wire up (SDP offer/answer, then a custom signalling channel). WebRTC is the only protocol on this list with sub-second glass-to-glass latency at production scale — the trade-off is that you need an SFU (mediasoup, LiveKit, Janus, Jitsi, Pion) to scale past a handful of peer-to-peer connections, and the CDN does not help you. WHIP (RFC 9725) and WHEP (Internet-Draft) standardise the HTTP front doors for ingest and egress.

HESP — High Efficiency Streaming Protocol. An HTTP-based protocol designed by THEO Technologies (now Dolby OptiView) and codified as the IETF Internet-Draft draft-theo-hesp. HESP delivers two parallel streams — a continuation stream that runs hot for steady-state playback and an initialisation stream of GOP-aligned points for joining and trick play. Production glass-to-glass latency: 400 milliseconds to 2 seconds; channel-change time as low as 100 ms. The trade-off is licensing and a smaller player ecosystem than HLS/DASH; the protocol is open as a draft but commercial implementations are concentrated in the HESP Alliance.

MoQ — Media over QUIC. The IETF moq working group's effort to define a single transport-layer protocol that combines the latency profile of WebRTC with the cacheability and scale of HLS/DASH. The current draft of record is draft-ietf-moq-transport-17 (January 2026), with companion drafts draft-ietf-moq-catalog and draft-ietf-moq-streaming-format. MoQ runs over QUIC (RFC 9000), inherits HTTP/3-style multiplexing, and is being deployed in production by Cloudflare, Meta, and Google for early production. Status today: pre-RFC. Cite as a draft until publication.

RTMP — Real-Time Messaging Protocol. Originally Adobe's Flash-era streaming protocol; the original specification is the Adobe 2009 PDF. RTMP is now formally deprecated for delivery (no modern browser supports Flash), but it remains the dominant contribution protocol — almost every encoder, streaming platform, and ingest endpoint speaks RTMPS (RTMP-over-TLS). The matrix below treats RTMP as a contribution-only protocol for 2026.

A note on SRT. SRT is also widely deployed for contribution and would deserve a column. We exclude it here only because this article is the Block 4 (delivery) comparison; SRT is covered in depth in the Block 3 deep dive. The matrix column for RTMP doubles as the "legacy contribution slot" so the eight-column structure stays clean.

The 8 × 12 Matrix

Each cell answers one criterion for one protocol. Numbers are 2026-current. Read every cell with the three habits from the previous section; the prose under each criterion explains the cell.

Criterion	HLS	LL-HLS	DASH	LL-DASH	WebRTC	HESP	MoQ	RTMP
1. Primary role	Delivery	Delivery	Delivery	Delivery	Real-time / Both	Delivery	Both	Contribution
2. Glass-to-glass latency	6–15 s	2–5 s	6–30 s	2–4 s	100–500 ms	0.4–2 s	0.5–2 s	2–5 s
3. Audience scale per stream	Millions	Millions	Millions	Millions	10k–100k (SFU); ∞ (WHEP+CDN)	Millions	Millions (target)	n/a
4. Browser support (May 2026)	Safari native; others via MSE	Safari native; others via MSE	MSE only; not Safari native	MSE only; not Safari native	Native in all major browsers	Player SDKs only	Experimental	Not supported (any browser)
5. CDN compatibility	Excellent	Excellent (with HTTP/2)	Excellent	Excellent (with HTTP/1.1 chunked)	None (UDP); WHEP-over-CDN early	Excellent (HTTP)	QUIC-aware CDN required	Specialised (Wowza, Cloudflare, etc.)
6. Transport	HTTP/1.1 or HTTP/2 over TCP	HTTP/2 over TCP	HTTP/1.1 or HTTP/2 over TCP	HTTP/1.1 chunked, HTTP/2 over TCP	UDP (RTP + DTLS-SRTP)	HTTP/1.1 or HTTP/2 over TCP	QUIC over UDP	TCP
7. Codec freedom	H.264, HEVC, AV1 (Apple-blessed list)	H.264, HEVC, AV1 (Apple-blessed list)	Any codec the container holds	Any codec the container holds	VP8, VP9, H.264, AV1, Opus, etc.	Codec-agnostic via CMAF	Codec-agnostic	H.264 / AAC mainly
8. DRM story	FairPlay (Apple)	FairPlay (Apple)	Widevine + PlayReady + FairPlay via CENC	Widevine + PlayReady + FairPlay via CENC	None (encrypted at SRTP layer; no Widevine/FairPlay/PlayReady)	Multi-DRM via CENC	Pre-standard	Not designed for DRM
9. Packaging format	MPEG-TS or fMP4	fMP4 (CMAF) only	fMP4 / WebM (DASH-IF profile)	fMP4 (CMAF)	RTP packets	CMAF	QUIC streams + objects	FLV (in transit)
10. Controlling spec	RFC 8216	Apple HLS Authoring Spec rev 2025-09	ISO/IEC 23009-1:2022	ISO/IEC 23009-1:2022 + DASH-IF LL guidelines	W3C WebRTC + RFC 8825–8866	draft-theo-hesp-06	draft-ietf-moq-transport-17	Adobe RTMP 2009 PDF
11. Maturity (2026)	Stable since 2009	Stable since ~2020	Stable since 2012	Stable since ~2020	Stable since 2017	Drafted in 2018; production since 2021	Pre-RFC; production pilots	Deprecated for delivery; ubiquitous in contribution
12. Operational cost shape	Low (HTTP/CDN)	Low-medium (HTTP/CDN + LL tuning)	Low (HTTP/CDN)	Low-medium (HTTP/CDN + chunked tuning)	High per session (SFU + TURN + bandwidth-est)	Medium (HTTP/CDN + HESP licensing)	Low at scale, R&D cost up front	Low

Table 1. The 8 × 12 protocol matrix, May 2026.

The prose below walks the matrix one criterion at a time. Each section is anchored on what the cell actually means in production — not the marketing version.

Criterion 1 — Primary role

Half of these protocols are delivery protocols and exist to push bytes from a media server to a viewer. The other half are something else. WebRTC is fundamentally a real-time interactive protocol that, with WHIP and WHEP, has grown an ingest leg (WHIP) and an egress leg (WHEP) so it can play either role. RTMP, despite being one of the most-talked-about names in streaming, has retreated to the contribution leg only: no modern browser plays RTMP, so it does not appear on a viewer's device. MoQ is designed from day one to handle both legs of the pipeline, which is one of the headline reasons it is being so closely watched.

The practical implication: pick the protocol that fits the role you are filling, not the protocol with the loudest brand. The single biggest architecture mistake we see in audits is teams trying to run WebRTC for the broadcast tail (millions of passive viewers), because they heard "WebRTC is the lowest latency". It is the lowest latency, but its per-session cost shape (Criterion 12) is wrong for a passive million-viewer audience by a factor of 10 to 20.

Criterion 2 — Glass-to-glass latency

Glass to glass means the elapsed time between light hitting the camera lens and light leaving the viewer's screen showing the same frame. It includes capture, encoding, contribution to the origin, packaging, distribution to the CDN edge, the player buffer, decoding, and rendering. The numbers in the matrix are well-tuned production ranges, not lab best-cases.

Let us do the arithmetic on a standard LL-HLS configuration to make this concrete. Assume a 2-second segment, broken into 200 ms parts.

Encoder latency:                     500 ms
Network to origin (RTMPS):           200 ms
CMAF chunking + packaging:           300 ms
Origin to edge (CDN propagation):    400 ms
Player part request + decode buffer: 1,500 ms
Decode + render:                     100 ms
TOTAL:                               3,000 ms = 3 seconds

That is a well-tuned LL-HLS production stack at around 3 seconds — well inside the matrix range of 2–5 seconds. The single biggest term is the player buffer; the player needs about one part's worth of margin in front of the decoder to absorb network jitter without stalling. Halve the part size to 100 ms and the buffer can shrink to 750 ms; total latency drops to about 2.3 seconds. Push the part size below 100 ms and most CDNs choke on the request rate.

WebRTC's 100–500 ms range is achievable because it skips the segment-and-buffer pattern entirely. There are no segments — the RTP stream is a continuous flow of packets, and the player keeps a jitter buffer measured in tens of milliseconds. The trade-off is that you cannot cache RTP packets on a CDN edge node, so the protocol has no way to amortise the cost across a million viewers (see Criterion 12).

HESP's 400 ms is impressive on paper. In production, the achievable number depends on the same edge-network and player-buffer terms as LL-HLS; HESP's published 400 ms case assumes the continuation stream is hot, which means the viewer is already mid-session. A first-load latency is closer to 1–2 seconds.

MoQ's 500 ms target is the published goal of the working group, not yet a measured production number across a large viewer base. Cite the working-group target with that caveat.

Figure 2. The same latency budget across seven delivery protocols. The player buffer is the single biggest term in every HTTP-based protocol; eliminating it is exactly what WebRTC does.

Criterion 3 — Audience scale per stream

Scale per stream is the size of the simultaneous audience a single live broadcast can serve. The HTTP-cacheable protocols — HLS, LL-HLS, DASH, LL-DASH, HESP — scale to millions of viewers per stream by caching segments at CDN edge nodes. The first viewer in a given city pays the cost of pulling the segment from the origin; every viewer after that gets it from the local edge cache.

WebRTC does not work this way. Each viewer holds a real-time RTP connection to an SFU, and the SFU forwards every packet to every viewer individually. A single SFU instance comfortably handles 1,000–5,000 viewers per stream; a cluster of cascaded SFUs (see Block 8) handles tens to hundreds of thousands. Past that, the cost per viewer-hour stops being competitive with HTTP delivery. The WHEP-over-CDN architecture is a 2024–2026 attempt to give WebRTC a CDN front — the egress connection is still RTP but the CDN handles the WHEP handshake; this is early in production deployment.

MoQ's scaling target is millions per stream by design — the protocol caches QUIC objects at QUIC-aware edge nodes. The architecture works in pilots; the size of the production audience as of 2026 is in the hundreds of thousands range, not millions.

Criterion 4 — Browser support

Browser support is the single criterion where Apple's special status in the ecosystem becomes a hard constraint. Native HLS playback in Safari uses the operating system's media stack — the AVPlayer on iOS, the equivalent layer on macOS. No JavaScript runs in the playback path; the browser handles segments, decryption, decoding, and rendering. The trade-off is that you cannot intercept the bytes for observability; Mux, Conviva, and friends rely on the MediaPlaybackQuality and VideoEvent APIs, which expose less than the MSE-based players do.

Chrome, Firefox, and Edge play HLS through a JavaScript library — most often hls.js — that parses the M3U8, fetches the segments, and feeds them into Media Source Extensions (MSE) for decoding. This is more flexible but slower to start (the JS bundle has to load) and slightly heavier on CPU.

DASH is the mirror image. Every non-Apple browser plays DASH through dash.js or Shaka Player over MSE; Safari does not have native DASH support, full stop. This is why the industry standard is to deliver both HLS and DASH from a single CMAF source — same bytes on the wire, different manifests.

WebRTC is the cleanest browser-support story on this matrix: native in Chrome, Firefox, Safari, Edge, Brave, and Opera, with the same RTCPeerConnection API. The differences are in implementation quality (Safari is the least feature-complete) and the codec list (Safari prefers H.264; Chrome happily speaks VP8, VP9, and AV1).

HESP and MoQ require player SDKs. There is no browser that plays them natively as of 2026. For HESP, the Dolby OptiView player SDK is the reference; for MoQ, Cloudflare and Meta have published experimental players, but no major browser vendor has shipped a built-in implementation.

RTMP does not play in any browser. Period. The 2020 deprecation of Flash ended browser-side RTMP playback; everything you read about "RTMP delivery to a browser" requires a server-side RTMP-to-HLS or RTMP-to-WebRTC transmuxer in front of the viewer.

Criterion 5 — CDN compatibility

If a protocol's segments fit cleanly into a CDN's cache, the operational cost story is good. If they do not, the protocol cannot achieve the per-viewer egress cost of an HTTP-cacheable protocol.

HLS, LL-HLS, DASH, LL-DASH, and HESP all use HTTP as their fetch primitive, so every CDN — Cloudflare, Akamai, Fastly, CloudFront, BunnyCDN — handles them by default. The only nuance is that LL-HLS and LL-DASH push the CDN harder: the player requests partial segments more often than a standard HLS player, and each request triggers a cache lookup. CDNs without optimised cache hierarchies for small objects (an origin shield, a tiered cache) can have a worse hit-ratio on low-latency delivery than on standard HLS. That is one of the silent cost shifts when you migrate from HLS to LL-HLS — you may need to upgrade the CDN tier or move to a streaming-specialised CDN.

WebRTC has no CDN compatibility. The RTP-over-UDP packets are session-specific, encrypted, and not cacheable. Scaling WebRTC is what SFUs are for; the only way to put it "on a CDN" is to wrap an emerging WHEP-over-CDN architecture, which essentially uses the CDN to handle the signalling handshake while the media still flows out of the SFU.

MoQ is CDN-friendly by design, but only on a QUIC-aware CDN. The CDN edge node has to understand QUIC streams and the MoQ object format to cache them; classic HTTP/1.1-only edges will not work. Cloudflare and Akamai have shipped QUIC support; some smaller CDNs have not yet.

RTMP is in a category of its own — it does not work on a general-purpose CDN. The ingest endpoint has to speak RTMP, which is why RTMP ingest is concentrated on specialised origins (Wowza, Cloudflare Stream, Mux, Bitmovin, Ant Media, Flussonic). Once the stream is inside the origin, it gets transmuxed to HLS/DASH/CMAF for delivery.

Criterion 6 — Transport

This is the layer where most of the latency story is decided. TCP-based protocols (HLS, LL-HLS, DASH, LL-DASH, HESP, RTMP) carry a handshake cost on every connection, retransmit lost packets in-order, and ramp up congestion windows through slow start. That is why their latency floor is 1–2 seconds even with perfect tuning: the network path is doing the right thing for reliable file transfer, not for real-time streaming.

UDP-based protocols (WebRTC) escape that floor. RTP runs over UDP; lost packets are either concealed by the decoder's packet-loss concealment or, for important reference frames, recovered through forward error correction. The handshake (DTLS plus ICE/STUN/TURN) is one-time and then irrelevant. There is no slow-start.

MoQ runs over QUIC, which is UDP-based but stream-multiplexed. QUIC inherits the no-head-of-line-blocking property of WebRTC and the cacheability property of HTTP — the combination is the architectural argument for MoQ being the long-term answer.

Criterion 7 — Codec freedom

What codecs can you actually ship through each protocol? HLS and LL-HLS are restricted to Apple's blessed list — H.264, HEVC, and (since iOS 17) AV1. You cannot, for instance, ship VP9 over HLS to Apple devices and expect it to play. DASH is the most permissive: any codec the underlying container holds is fair game. WebRTC has a different short list (VP8, VP9, H.264, and AV1 in 2026) defined by the W3C, and Safari's WebRTC implementation in particular requires H.264.

HESP is codec-agnostic in the spec, but commercially deployed implementations target H.264 and HEVC for now.

MoQ inherits codec freedom from QUIC (no codec constraint at the transport layer) and from the draft-ietf-moq-streaming-format (which is being defined separately for video). In 2026, most pilots ship H.264 or AV1.

RTMP is essentially locked to H.264 plus AAC for video and audio — the FLV container that RTMP transports does not formally support newer codecs in a way mainstream encoders honour, even though some implementations have hacked HEVC support in.

Criterion 8 — DRM story

DRM (digital rights management) determines whether you can ship premium licensed content (Netflix-tier movies, live sport rights, paid SVOD) through a protocol. Premium content owners require three DRM systems — FairPlay for Apple, Widevine for Android and Chromebooks, PlayReady for Windows and smart TVs — and the bytes on the wire have to be encrypted in a way all three can decode.

The standard for that is Common Encryption (CENC), defined in ISO/IEC 23001-7. CENC encrypts the video stream once with a single key, and each DRM system wraps that key in its own license format. HLS, LL-HLS, DASH, LL-DASH, and HESP all support CENC, so you ship the same encrypted segments to all three ecosystems. The DRM 101 article covers the architecture in detail.

WebRTC has no CENC equivalent. The protocol encrypts media at the transport layer with DTLS-SRTP — every WebRTC stream is encrypted by design — but the encryption is session-specific and does not carry a multi-system license envelope. You can layer your own DRM scheme on top, but no premium content owner will currently license you to ship through WebRTC. That alone disqualifies WebRTC for many OTT use cases.

RTMP is not designed for DRM. RTMPS gives you TLS-encrypted transport, but the content itself is not protected with a content key after it leaves the connection — once it reaches the origin, it is plaintext.

MoQ's DRM story is pre-standard. The working group has discussed how to layer CENC over QUIC objects but has not landed on a final design. Treat as TBD.

Criterion 9 — Packaging format

What sits on the wire? HLS originally shipped MPEG-TS, the broadcast-era container; modern HLS (since 2016) supports fragmented MP4 (fMP4) and CMAF, and LL-HLS requires fMP4 in CMAF profile. DASH was designed around fMP4 / WebM from day one. WebRTC ships RTP packets — there is no container, just RTP headers around the encoded media.

The reason this matters: if both HLS and DASH ship the same CMAF bytes, you only have to encode and store one set of files. This is the package-once-deliver-many architecture that has driven the industry over the past five years. The CMAF article walks the format in detail.

HESP packages in CMAF. MoQ packages as a stream of QUIC objects with a published draft profile for video.

Criterion 10 — Controlling specification

• HLS: IETF RFC 8216 — https://www.rfc-editor.org/rfc/rfc8216. Read this for the base HLS specification.
• LL-HLS: Apple HLS Authoring Specification for Apple Devices, revision 2025-09. Apple owns LL-HLS extensions; no separate IETF document defines them. Importantly, Apple removed HTTP/2 server push from this document in the September 2023 revision — many older articles still describe push as required, and they are out of date.
• DASH: ISO/IEC 23009-1:2022 (paywalled) plus the DASH Industry Forum Implementation Guidelines (free, mirror the normative text closely).
• LL-DASH: ISO/IEC 23009-1:2022 with the DASH-IF low-latency guidelines layered on top.
• WebRTC: W3C WebRTC 1.0 Recommendation plus the IETF RFC 8825–8866 family. The W3C document covers the JavaScript API; the IETF RFCs cover the transport, signalling, and security model.
• HESP: draft-theo-hesp-06 (IETF Internet-Draft). Subject to revision before RFC publication.
• MoQ: draft-ietf-moq-transport-17 (January 2026) plus companion drafts. Subject to revision; do not cite as a final RFC.
• RTMP: Adobe's 2009 PDF, archived. There has been no maintained successor.

Criterion 11 — Maturity

Maturity is the answer to how risky is it for me to ship this protocol in 2026? HLS, LL-HLS, DASH, LL-DASH, and WebRTC are all rock-solid: each has been in production at internet scale for at least five years and has a large pool of engineers who have shipped them. HESP is stable but limited to the HESP Alliance ecosystem — the protocol works, but the pool of engineers and the tooling is narrower than HLS/DASH. MoQ is exciting and experimental: shipping a customer-facing product on MoQ in 2026 means betting the architecture on a pre-RFC standard.

RTMP is mature for contribution and not for delivery — the protocol is two decades old, every encoder speaks it, but every browser stopped supporting it in 2020.

Criterion 12 — Operational cost shape

Cost has three components: per-viewer egress, infrastructure, and engineering. The matrix's "cost shape" cell summarises the dominant component for each protocol.

HLS, LL-HLS, DASH, LL-DASH, HESP are all CDN-dominated cost shapes — the per-viewer cost is whatever the CDN charges you per gigabyte out, multiplied by the average viewer-hours. Infrastructure cost (origin, packager, DRM key server) is amortised across the audience and is a small per-viewer term at scale. Engineering cost is a 1–2 person team for steady-state HLS/DASH operations.

For a back-of-envelope number: 1 hour of LL-HLS at 5 Mbps to 100,000 concurrent viewers, on a $0.005/GB CDN tier, costs about $1,125 per hour of broadcast in CDN bandwidth alone. The same broadcast at standard HLS (also 5 Mbps) costs the same — the bitrate is the same. The latency tier does not change the cost; only the bitrate ladder does.

WebRTC is a per-session cost shape. Every viewer maintains a session with an SFU; the SFU has bandwidth out, CPU, and memory cost per session. As a rough number, a well-tuned SFU node serves 1,000–2,000 viewers at 1–2 Mbps each. Same 100,000-viewer broadcast: 50–100 SFU nodes plus a TURN tier plus signalling. The per-viewer-hour cost is 5–20× CDN-delivered HLS. Engineering cost is also higher: WebRTC at scale needs an in-house team that understands jitter buffers, bandwidth estimation, and SFU operations.

MoQ is designed to converge the two cost shapes. Pilots indicate per-viewer cost in line with HLS/DASH at scale; up-front R&D cost is significant — you are integrating a draft protocol.

RTMP has a contribution-only cost shape — a single ingest connection per stream — and is therefore not in the same comparison as delivery cost.

Where Fora Soft Fits In

We have shipped video products since 2005 across video conferencing (WebRTC stacks built on mediasoup, LiveKit, and Pion), OTT and Internet TV (HLS, LL-HLS, DASH, LL-DASH over multi-CDN), video surveillance (low-latency WebRTC plus RTSP at the camera edge), e-learning (hybrid LL-HLS broadcast with WebRTC moderator overlays), telemedicine (WebRTC end-to-end with consent-based recording in HLS), and AR/VR streaming. In every one of those projects, the question "which protocol?" had a different answer — which is why we wrote this matrix article in the first place. If your team is making a build-vs-buy call and the right cells are unclear, talk to a streaming engineer — there is no substitute for a 30-minute scope conversation with someone who has shipped the protocol you are evaluating in the vertical you are evaluating it for.

Common Mistakes When Reading This Matrix

A handful of misreads come up in every protocol-selection conversation we run. Avoid them.

Treating latency as the only criterion. Latency is the cell most readers anchor on, because vendor marketing has trained the market to think "lower latency = better protocol". It is one of twelve cells. A passive YouTube-style audience does not benefit from sub-second latency and the cost shape that delivers it. The right question is what latency tier you need — sub-second, 2–5 seconds, or 10–30 seconds — and which protocol fits that tier at the scale you ship.

Reading "supports CENC" as "supports premium content". Supporting CENC is necessary for premium content but not sufficient. You also need the right DRM licensing relationships, your player has to ship the right EME implementation, and your manifest has to declare the right content key IDs. The matrix shows the spec-level capability; production readiness needs more.

Confusing "stable" with "deployed at the scale you need". WebRTC is stable as a spec. Whether your team can run WebRTC at 50,000 concurrent viewers per stream is a separate question — at that scale you need SFU expertise that has been hard to hire since 2020. Likewise, HESP is stable as a protocol but the pool of engineers who have shipped it in production is small.

Picking on browser percentage without looking at the device share. "Native in 95% of browsers" hides a 5% slice that may be 60% of your revenue. If that slice is iOS Safari for an iPhone-heavy app, the matrix tells you DASH is wrong even though it scores well on every other criterion.

Believing the marketing latency number. Vendor benchmarks measure protocol latency on their own infrastructure, on their own well-tuned encoders and players, often inside a single data centre. Glass-to-glass latency in production has 4 more terms (CDN propagation, last-mile network, viewer device decode, viewer device render) and routinely lands 2–3× higher than the benchmark. The matrix's ranges are the well-tuned production ranges.

How To Use This Matrix In a Real Decision

The matrix is the data layer. The decision layer is the protocol decision tree, which walks you from "what are you building?" to "ship this stack". For most teams in 2026, the answer falls into one of three lanes:

• Broadcast tail of millions, latency tier 2–5 seconds: LL-HLS + LL-DASH off a single CMAF source. Same encoded segments, two manifests, one CDN tier. Cost-dominated by egress; engineering team can be small.
• Interactive tier (host, guests, audience under 100k), latency tier sub-second: WebRTC, fronted by WHIP/WHEP for the HTTP handshake, scaled on an SFU cluster. Higher per-viewer cost but the only protocol that hits sub-second.
• Hybrid (live shopping, town halls, sports with control-room monitoring): combine the two — WebRTC/WHEP for the interactive ring, LL-HLS for the broadcast tail, off the same CMAF source. Read the hybrid stacks article for the four canonical patterns.

MoQ and HESP fit niche cases today (fast channel change, pre-RFC architecture pilots). Most production teams in 2026 should still ship HLS-or-DASH plus WebRTC.

What To Read Next

• The Switching Protocols Reality: Hybrid Stacks — the architecture that combines the protocols in this matrix.
• Choosing a delivery protocol in 2026: a decision tree — the BOFU decision article that ranks for "best streaming protocol".
• The delivery protocol family tree — the lineage and history behind the eight protocols.

CTA Block

• Talk to a streaming engineer — book a 30-minute scoping call to walk through the matrix on your own product.
• See our case studies — Fora Soft video streaming portfolio.
• Download the matrix as a one-page card — Protocol comparison matrix card (PDF).

References

1. RFC 8216 — HTTP Live Streaming (IETF, August 2017). Tier 1. The base specification for HLS.
2. HLS Authoring Specification for Apple Devices, revision 2025-09 (Apple). Tier 1. Controlling document for LL-HLS, including the September 2023 removal of HTTP/2 server push.
3. ISO/IEC 23009-1:2022 — Dynamic adaptive streaming over HTTP (DASH) — Part 1 (ISO/IEC, 2022). Tier 1. The DASH base specification (paywalled).
4. ISO/IEC 23000-19:2024 — Common Media Application Format (CMAF) for segmented media (ISO/IEC, 2024). Tier 1. Package-once container for HLS/DASH/HESP.
5. ISO/IEC 23001-7 — Common Encryption (CENC) (ISO/IEC). Tier 1. Multi-DRM key envelope standard.
6. RFC 9725 — WebRTC-HTTP Ingestion Protocol (WHIP) (IETF, March 2025). Tier 1. WebRTC ingest HTTP handshake.
7. draft-ietf-wish-whep — WebRTC-HTTP Egress Protocol (WHEP) (IETF Internet-Draft, 2026 revision). Tier 1. WebRTC egress HTTP handshake; subject to change before RFC publication.
8. W3C WebRTC 1.0 (W3C Recommendation). Tier 1. JavaScript API and behaviour.
9. RFC 8825–8866 family (IETF). Tier 1. The WebRTC transport, signalling, and security RFC bundle (start at RFC 8825 for the architecture).
10. draft-theo-hesp-06 — High Efficiency Streaming Protocol (IETF Internet-Draft). Tier 1. HESP protocol definition; subject to revision.
11. draft-ietf-moq-transport-17 — Media over QUIC Transport (IETF Internet-Draft, January 2026). Tier 1. MoQ transport-layer specification; subject to revision before RFC publication.
12. RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport (IETF, May 2021). Tier 1. Underlying transport for MoQ.
13. Adobe RTMP Specification (Adobe, 2009 archived PDF). Tier 1. Original RTMP specification; no maintained successor. The RTMP article in Block 4 (RTMP for distribution and why it's truly dying) cites it.
14. Mux — HLS vs. DASH: What's The Difference? (Mux). Tier 3. Practitioner reference — used to corroborate the Apple-native vs MSE story; the spec is the source of the underlying claim.
15. Cloudflare Stream — Live video docs (Cloudflare). Tier 3. Practitioner reference for multi-protocol delivery topology.
16. Dolby OptiView — What is HESP? (Dolby). Tier 3. Vendor reference for HESP's 400 ms latency and 100 ms zapping claim; cross-referenced with the IETF draft.
17. Wowza — What Is Media Over QUIC (MoQ)? (Wowza, 2025). Tier 4. Vendor explainer used as orientation only; the draft is the source of truth.
18. Ant Media — Video Streaming Protocols (2026 Update) (Ant Media, 2026). Tier 4. Multi-protocol output pipeline reference.
19. DASH Industry Forum — Implementation Guidelines (DASH-IF). Tier 1/2. Open mirror of the ISO 23009-1 normative requirements; used wherever ISO is paywalled.