Why This Matters
The 2020s have produced four serious sub-second delivery protocols on the open internet: WebRTC (and the WHIP/WHEP signalling pair around it), LL-DASH with chunked CMAF, LL-HLS, and HESP. The first three are open standards with multiple independent implementations. HESP is not — it is a single-vendor protocol developed by THEO, governed by the THEO-and-Synamedia-founded HESP Alliance, documented in an expired IETF informational draft, and licensed under royalty terms that scale with the number of viewers. That governance asymmetry is, in 2026, the single most important fact about HESP and the reason it appears in almost no protocol-selection decision-tree by default.
Yet HESP is also genuinely good engineering. The two-stream architecture solves a problem the open standards solve only awkwardly: a viewer who joins a stream at an arbitrary moment can pull one Initialization Packet, start the decoder on its key frame, and then immediately splice into the Continuation Stream — no waiting for the next IDR in a segment, no manifest round-trip, no DNS lookup. That is the mechanism behind the 100-ms zapping claim, and it is mechanically lower than any HLS or DASH-based player can match because those protocols always need a full manifest fetch plus a key-frame-aligned segment.
This article is the canonical reference on HESP for the engineers, architects, and product people who keep encountering it in vendor pitches, RFP requirements from broadcasters, and the more aggressive iGaming and live-commerce stacks. We will cover what HESP actually is on the wire, where the latency and bandwidth claims come from, what the licensing reality is in 2026, which platforms ship it today, and the cases where picking HESP is the right answer despite the open-standards alternatives.
What HESP Is — In One Page
HESP is an HTTP adaptive streaming protocol that runs on the same CDN infrastructure as HLS and DASH but uses a custom JSON manifest format and a custom two-stream segment model. The protocol was first introduced by THEO Technologies in 2018, demonstrated publicly at NAB 2019, formally announced through the HESP Alliance in 2020, submitted to the IETF as draft-theo-hesp-00 in May 2021, and most recently revised as draft-theo-hesp-06 in April 2024. As of May 2026, that draft has expired without renewal; the IETF document carries category "Informational" (not Standards Track), is an individual submission rather than a working-group document, and explicitly states that "version 2 of the HESP protocol" is the version it describes. There is no newer IETF document.
Mechanically, every HESP track is split into two streams that are encoded and packaged from the same source media but addressed and delivered separately. The Initialization Stream is a sequence of independently-fetchable Initialization Packets, each one a complete CMAF bootstrap — a CMAF header (ftyp, moov), an independent key-frame media sample, and an in-band metadata event (emsg box, custom URN urn:theo:hesp:2020) that carries a JSON pointer {"index": N, "offset": N} telling the player where to start reading the Continuation Stream. The Continuation Stream is a regular CMAF live stream split into chunks, addressed by HTTP byte-range requests, that the player consumes contiguously once it has bootstrapped from an Initialization Packet.
The behavioural pay-off is what makes HESP distinctive. A new viewer joining the stream fetches one Initialization Packet from the URL init/{initId} (or the special token now for "give me the latest"), feeds the CMAF bootstrap into its decoder, reads the {index, offset} pointer from the embedded emsg, and issues an HTTP Range request against the Continuation Stream starting at that byte offset. From that point on the player is in normal chunked-CMAF playback mode — but it never had to wait for the next segment boundary or the next IDR frame in a regular segment, because the Initialization Packet was a key frame. The same mechanism makes channel-change instant: switching to a new variant pulls a new Initialization Packet, key-frames the decoder, and splices into the new Continuation Stream within one round-trip. The HESP draft (§2.2) describes this as the property that "the Continuation Stream can start playback immediately after an Initialization Packet, allowing for very fast channel start and switch times".
The wire transport is plain HTTP/1.1 or HTTP/2 — no QUIC requirement, no WebSockets, no WebRTC, no proprietary framing. The CDN sees regular range requests against regular file-like URLs and caches them like any other static-ish asset. That is the architectural claim: open low-latency at sub-LL-HLS numbers, over the CDN you already pay for.
Figure 1. The HESP two-stream architecture. A joining viewer pulls a single Initialization Packet, reads the embedded {index, offset} pointer, and splices into the Continuation Stream at the matching byte position — no segment-boundary wait, no IDR wait.
Where The 400 ms And 100 ms Numbers Come From
The two latency numbers everyone quotes — 400 ms glass-to-glass and 100 ms zapping — deserve precise accounting because they are correct in one specific setup and misleading in most others.
Glass-to-glass latency. The latency budget on a sub-second HESP path is dominated by the same things that dominate any low-latency HTTP-based delivery: encoder pipeline, packager turnaround, the ingest leg, the CDN leg, and the player jitter buffer. HESP earns its low number by aggressively chunked CMAF on the Continuation Stream — the "Maximum Gain" profile defined in the draft (§5.1.1) places one media sample per CMAF chunk, which is the smallest legal unit and the floor of HTTP-chunk-based latency. Take a typical 50 fps live stream: one sample arrives every 20 ms; the chunk is published as soon as that one sample finishes encoding; the CDN forwards the chunk as a single HTTP/1.1 chunked-transfer-encoded fragment; the player reads it within one network RTT of publication. The arithmetic, out loud:
- Encoder, 20 ms per sample at 50 fps. One sample per chunk.
- Packager forwarding (CMAF chunk close + push), 10 to 30 ms.
- Ingest leg (encoder to packager origin), 5 to 50 ms depending on geography.
- CDN cache miss → origin → cache fill → edge response, 20 to 80 ms.
- Edge to player, 10 to 100 ms.
- Player jitter buffer, 100 to 300 ms (configurable; THEO's player ships with 150 ms default for low-latency profile).
Sum on a same-region wired path: roughly 300 to 600 ms. THEO's published interop demonstrations report 330 ms for a clean same-region path on the Maximum Gain profile, which is the source of the "400 ms" headline. On a transatlantic path the number rises to 600 to 900 ms because each transatlantic RTT eats roughly 100 ms. The 400 ms claim is real and achievable, but only on a clean Maximum Gain configuration with a healthy jitter buffer and a same-region delivery path.
Channel-change ("zapping") latency. This is where HESP's two-stream model produces a genuinely different number from anything else on the market. A typical HLS player changing from variant A to variant B at the user's command must: (a) fetch the new variant's manifest (or look it up in cache), (b) decide what segment to start at, (c) fetch a segment containing or starting with an IDR frame, (d) prepare the decoder. The HLS spec requires a key-frame-aligned switch at a segment boundary; the actual measured time on a fast CDN runs 2 to 6 seconds depending on segment duration and cache warmth. A HESP player making the same switch fetches one Initialization Packet (the special URL init/now returns the most recent one), key-frames the decoder, reads the {index, offset} pointer, and issues a Range request against the new variant's Continuation Stream. THEO's measurements report this round-trip on a warm CDN at well under 100 ms — typically 30 to 80 ms for the Init Packet + 20 to 50 ms for the Continuation Range request, total 50 to 130 ms. The "20× faster than industry-standard low-latency streaming" claim from the HESP Alliance white-paper is grounded in this comparison and is mechanically defensible.
Bandwidth. The third headline claim — 10 to 20 percent less bandwidth than chunked CMAF or LL-HLS for the same visual quality — is more nuanced. HESP saves bandwidth in two places. First, the Maximum Gain profile is brutally efficient at the bit level because it allows the encoder to reference long inter-frame chains (each sample can reference only its immediate predecessor) and skip the structural overhead LL-HLS imposes through "parts" and rendition reports. Second, HESP players switch variants on key-frame events from the Initialization Stream rather than on segment boundaries — that means the player can switch down immediately when throughput drops, avoiding the wasted high-bitrate segment LL-HLS would still finish downloading. THEO's tested numbers compare a 6 Mbps HESP Max-Gain stream against a 6.6 to 7.3 Mbps LL-HLS equivalent at matched quality. The savings are real but the matched-quality test method varies by lab; for procurement, treat the 10 to 20 percent as "credible in a benchmarked test, model 0 to 15 percent for your traffic mix".
Figure 2. The four sub-second protocols on a single latency budget chart. HESP earns its 400 ms slot through aggressively chunked CMAF — one sample per chunk in the Max-Gain profile — while staying on standard HTTP.
The Two Profiles — Max Gain And Compatibility
The draft defines two profiles a HESP encoder/packager can produce, and they trade latency for compatibility in opposite directions.
The Maximum Gain profile (§5.1.1) is the latency-minimum configuration: each CMAF chunk contains exactly one media sample, each sample references only the immediately preceding sample (no traditional GOP structure), and segments can be arbitrarily long because the boundary no longer matters — every chunk is independently routable. The "Max-Gain" name describes the bandwidth gain over conventional GOP-structured streams: with no full GOP boundary inside a typical segment duration, you avoid the conventional IDR-frame overhead distribution that classical HLS and DASH require for splice points. The trade-off is that decoders without HESP-aware buffering will not understand the stream — Max-Gain output is HESP-specific, not playable in a vanilla HLS or DASH player.
The Compatibility profile (§5.1.2 in older drafts, retitled in -06) preserves a conventional CMAF segment and GOP structure — 1 to 30 second segments, regular I B...B P B...B P GOPs with up to 4 B-frames per GOP — so the same packager output can be served as both HESP and conventional HLS/DASH by sending the Initialization Stream's emsg pointers when the request comes from a HESP player and serving the regular manifest when the request comes from a conventional player. This is the production pattern most HESP deployments actually use: HESP for the live edge (the sub-second viewers), HLS as the broadcast tail (the device coverage and the cheap-egress majority), one packager pipeline serving both.
For procurement, the profile choice is significant. If you have committed to HESP for sub-second and accept a HESP-specific player on every device, Max-Gain is the right answer and delivers the headline latency numbers. If you want to keep an HLS fallback for the long tail of devices (smart TVs, older mobile apps, the ~30 percent of the 2026 streaming endpoint population that has no working HESP player), the Compatibility profile is the practical choice — you give up some of the bandwidth gain to keep one packaging pipeline.
The Manifest — Why JSON, And What It Looks Like
HESP does not use M3U8 or MPD. Its manifest is a custom JSON document with MIME type application/vnd.theo.hesp+json, requested as IANA registration in §9 of the draft. The JSON carries the same conceptual structure as DASH: a single root Manifest, one or more Presentations (analogous to DASH Periods), one or more SwitchingSets per Presentation (analogous to AdaptationSets), and one or more Tracks per SwitchingSet (analogous to Representations). Each Track points at an Initialization Stream URL template and a Continuation Stream URL template, both using {initId} and {segmentId} placeholders (e.g., init/{initId:08d} and content-{segmentId:06d}.mp4).
The minimal HESP manifest for a single live event with two video variants and one audio variant runs to roughly 80 lines of indented JSON — comparable in size to a multi-variant HLS master playlist plus its child playlists, and structurally simpler than the equivalent DASH MPD. The protocol relies on the manifest being relatively static: variants and presentations are announced; the live edge moves through them via the Continuation Stream's chunked HTTP transport, not through manifest reload. That static-manifest property is part of why HESP scales well over CDNs — the manifest itself is cacheable for the duration of the event.
There are practical consequences. First, a HESP player is not just a different parser bolted on to an HLS/DASH player — it is a full new media engine. Existing HLS.js, dash.js, Shaka Player, and Video.js cannot play HESP; the only production HESP players in 2026 are THEO's commercial player, the open-source HESPlayer reference implementation, NativeWaves's player, and a handful of vendor-specific embeds (Gcore, MainStreaming). Second, there is no native HESP support in browsers — the player is always a JavaScript media engine driving the browser through Media Source Extensions (covered in our MSE article). On iOS Safari, where MSE only became available in iOS 17.1 (2023), HESP works only on recent enough versions. Older iOS Safari has no HESP path at all.
The HESP Alliance, The IETF Status, And The Licensing Question
Here is where HESP's positioning gets complicated and where most protocol-selection decisions actually turn.
THEO Technologies (the Belgian player vendor behind THEOplayer) is the protocol's author and the patent-holder on the underlying technique. The HESP Alliance, formed in 2020 with Synamedia as the second founder, is the licensing and certification body. The Alliance operates a two-tier membership: Gold members have no annual revenue ceiling; Silver members are capped at USD 10 million annual revenue. Founding members are THEO and Synamedia; public Silver members as of May 2026 include Gcore (joined 2022), MainStreaming, EZDRM (joined 2024 for DRM-aware HESP playback), SyncWords (joined for live caption integration), NativeWaves, and Hoki. Public Gold member count is small — substantially under ten.
The licensing model has three commercial tracks. Initiation of HESP streams (i.e., publishing a HESP feed) is royalty-free to anyone. Non-commercial use of HESP is royalty-free. Commercial HESP client use is the paid tier and offers three royalty models the licensee picks from: a usage-volume model (per GB or per stream-hour delivered), a user-subscription model (per paying viewer per month), or a per-device royalty (per certified HESP-capable endpoint shipped). The Alliance describes the commercial terms as "fair, reasonable and non-discriminatory" (FRAND), and publishes the rate cards on its public Royalty Rates page; specific numeric rates are unpublished and negotiated per licensee under NDA.
The IETF status is, simultaneously, the protocol's most-cited credential and its largest credibility problem. The IETF document is genuinely real — draft-theo-hesp-06, published April 2024, individual submission, category Informational. But the IETF treats individual informational drafts as published reference material, not as IETF standards. The document explicitly carries IETF boilerplate stating that "Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as 'work in progress.'" The current -06 draft expired on 19 October 2024 and has not been refreshed. There is no IETF working group reviewing HESP, no scheduled progression to RFC, and no obvious path to standardization because the underlying technique is patented and the patent licensing is not RAND-Z (royalty-free).
The structural comparison worth making is to LL-HLS and LL-DASH. LL-HLS is documented in Apple's HLS Authoring Specification, a living document Apple updates 1–3 times a year, with multiple independent player implementations (hls.js, Shaka Player, native iOS, Bitmovin player, THEOplayer itself). LL-DASH lives in ISO/IEC 23009-1 and DASH-IF's open guidelines, also with multiple independent implementations. WebRTC delivery lives across the W3C and IETF RFC 8825–8866 family, with implementations in every modern browser. All three competitors are open standards with multiple independent implementations. HESP is one vendor (THEO), one specification (an expired informational draft), and one or two commercial player implementations. That is not a fatal objection — Adobe Flash ran the streaming world for a decade with the same governance structure — but it is the single most-relevant consideration for any procurement decision that values vendor independence and ten-year roadmap durability.
Vendor Support And The 2026 Deployment Map
The vendor-support table below summarises HESP coverage across the platforms a 2026 streaming product is likely to evaluate. The "HESP support" column distinguishes between origin/packager (can your encode-side pipeline produce HESP), CDN (will your CDN serve the HESP wire), and player (can the viewer's device decode and render the stream).
| Vendor / Platform | HESP packager | HESP CDN | HESP player | Notes |
|---|---|---|---|---|
| THEO Technologies | Yes (origin SDK) | n/a | THEOplayer (web, iOS, Android, smart TVs) | The reference implementation; every HESP deployment pairs with at least one THEO component. |
| Synamedia | Yes (Live & VOD origin) | n/a | n/a | Founding Alliance member; HESP-native origin. |
| Gcore | Yes | Yes (Gcore CDN, HESP-Ready) | Yes (via THEOplayer integration) | Silver member; offers HESP packaging + delivery as a managed service since 2022. |
| MainStreaming | Yes | Yes (MainStreaming CDN) | Yes (integrated) | Silver member; HESP integrated into the MainStreaming live workflow. |
| NativeWaves | Yes | n/a | NativeWaves player | Specialised in synchronous multi-angle sports. |
| EZDRM | n/a | n/a | DRM integration only | Silver member; enables CENC-based DRM for HESP. |
| Bitmovin | Partial — encode pipeline; HESP packager available through partner | No | No native HESP player | Bitmovin's roadmap remains LL-HLS / LL-DASH first. |
| Cloudflare Stream | No | No | No | HLS / DASH / WebRTC only. |
| AWS MediaPackage | No | No | No | HLS / DASH / CMAF only. |
| AWS MediaLive | No | n/a | n/a | No HESP output. |
| Akamai | No (no HESP packager) | Yes (HESP wire passes through) | No | Akamai CDN delivers HESP if upstream produces it; no first-party HESP service. |
| Cloudfront | Yes (wire) | Yes (wire) | No | Pass-through. |
| Fastly | Yes (wire) | Yes (wire) | No | Pass-through. |
| Mux Live | No | No | No | HLS / WHEP only. |
| Vimeo Livestream | No | No | No | HLS / DASH. |
| Bitmovin Player | No | n/a | No | Roadmap LL-DASH / LL-HLS / CMAF. |
| hls.js | No | n/a | No (cannot play HESP) | HLS only. |
| Shaka Player | No | n/a | No | HLS / DASH. |
| dash.js | No | n/a | No | DASH. |
| Video.js | No | n/a | No | HLS / DASH plugins only. |
A Worked Example — A Live Sports Betting Stream On HESP
Let us trace one concrete configuration that justifies the HESP commitment. We are streaming a live football match at 1080p50 to roughly 80,000 concurrent viewers across a Tier-1 European territory. The product requirement is strictly sub-second glass-to-glass latency because the stream is used inside the operator's live in-play betting product — viewers must see the actual play moment at most a few hundred milliseconds before betting markets close. WebRTC was evaluated and rejected on cost grounds at the 80,000-concurrent viewer count (WebRTC's per-viewer SFU resource cost would have required a TURN/SFU mesh of roughly 80 to 120 servers across the territory). LL-HLS was evaluated and rejected on latency grounds — its 3 to 6 second floor lets the in-play betting market close before the visual event is shown.
The production stack: Synamedia's HESP-aware origin packages the live encoder output (Bitmovin Encoder OTT, 6 Mbps + 3 Mbps + 1.5 Mbps adaptive ladder, H.264, 50 fps, Max-Gain profile, one sample per CMAF chunk), Gcore CDN handles distribution across Europe, THEOplayer Web runs in every customer's browser tab (or THEOplayer iOS / Android in the mobile apps).
The wire trace for a joining viewer: the player loads the HESP JSON manifest from https://cdn.example.com/sport-event-42/manifest.hesp.json (one round-trip, 30 ms). The manifest identifies the active Switching Set's three video tracks and one audio track; the player picks the 3 Mbps middle variant (its bandwidth estimator started conservative). It fetches init/now from the 3 Mbps Initialization Stream URL: the CDN serves the most recent Init Packet, 24 KB, in one HTTP/2 request (35 ms RTT + 8 ms transfer). The player feeds the CMAF header to its media-source decoder, reads the emsg pointer {"index": 4217, "offset": 1283904}, and issues an HTTP Range request Range: bytes=1283904- against the Continuation Stream URL content-004217.mp4. The CDN serves the Range from a hot cache (12 ms response). The first decoded frame hits the viewer's screen approximately 315 ms after the underlying camera captured it — measured against a millisecond-resolution clock super-imposed on the source.
During play the player switches to the 6 Mbps variant when its bandwidth estimator stabilises high; the switch is mechanically identical to the join — pull the new variant's init/now, key-frame the decoder, splice into the new Continuation Stream — and completes in roughly 65 ms with no visible artefact to the viewer. The 80,000 concurrent viewers across the territory deliver an aggregate bandwidth bill of approximately 290 Gbps on the 6 Mbps tier, paid to Gcore at their HESP-CDN rate. The licensing fee paid to the HESP Alliance is calculated under the per-viewer-subscription model — the operator already has a known monthly active count for the betting product, so the per-MAU rate gives a stable cost per accounting period.
The same content path on LL-HLS would have hit roughly 4 seconds glass-to-glass — 13× HESP — with the in-play betting market closing 4 seconds after the play happened on the pitch, a product failure for this specific use case. The same path on WebRTC would have hit roughly 280 ms glass-to-glass — slightly better than HESP — at roughly 6× the CDN-side cost because every viewer is a peer on an SFU. The HESP path delivered the latency-budget target and the cost-economics target simultaneously.
Figure 3. The three sub-second protocols on one delivery problem. HESP earns its place when latency must be sub-second AND CDN economics must scale to tens of thousands of viewers per stream — neither LL-HLS nor WebRTC hits both targets simultaneously at that scale.
When To Choose HESP — A Decision Framework
HESP fits a specific intersection of requirements; outside that intersection, one of the open standards is the right answer. The framework below is the one we walk clients through in 2026.
Choose HESP when: (a) the latency budget is strictly under one second and ideally under 500 ms; (b) the audience is medium-to-large (5,000 to 1,000,000 concurrent viewers per stream — large enough that WebRTC's per-viewer cost is uncompetitive); (c) you are willing to commit to a vendor stack (THEO + one HESP packager + one HESP-aware CDN); (d) the device coverage requirement is modern browsers and modern mobile apps (no legacy smart TV or set-top box requirement that requires a working HLS-only fallback); (e) the use case rewards channel-change speed — live betting, live shopping, multi-angle sports, second-screen iGaming. The licensing relationship is part of the deal.
Choose WebRTC / WHIP / WHEP when: latency must be sub-second AND the audience is bounded (under 5,000–10,000 concurrent per stream) where WebRTC's per-viewer SFU cost still works AND the contribution side is also WebRTC.
Choose LL-HLS when: latency can be 3 to 6 seconds, audience is unbounded, device coverage includes the long tail (legacy smart TVs, set-top boxes), or you value an open standard with multiple independent player implementations over the absolute latency floor.
Choose LL-DASH / CMAF chunked when: you are already on a DASH-native toolchain (Bitmovin / Shaka Packager) and the latency target is 3 to 5 seconds.
Choose classical HLS when: latency is not the constraint and CDN egress economics dominate the procurement decision.
Figure 4. The 2026 sub-second delivery decision tree. HESP is the right answer at the intersection of "sub-second", "medium-to-large audience", and "willing to commit to the THEO vertical stack" — outside that intersection, one of the open standards wins.
Common Mistakes — The Pitfalls We See On HESP Deployments
A short list of the failures we see most often when bringing up a new HESP delivery link or evaluating one in a procurement cycle. Most are not bugs in the protocol but mismatches between what HESP delivers and what the project actually needed.
Pitfall 1: Treating HESP as drop-in replacement for HLS. It is not. The player is different, the manifest is different, the CDN cache keys are different, the DRM integration is different (CENC is supported per draft §7 but the integration uses HESP-specific ext-X-key-replacement semantics). A team that plans to "just turn on HESP" against an existing HLS pipeline discovers within a sprint that they are rebuilding the player layer and renegotiating the CDN contract.
Pitfall 2: Picking the Max-Gain profile and losing HLS fallback. Max-Gain output is HESP-only — it cannot be served as HLS to a browser without a HESP player. A deployment that promises "HESP for low-latency and HLS for the long tail" must use the Compatibility profile, not Max-Gain. The latency target then sits closer to 600 to 900 ms because the chunks are larger.
Pitfall 3: Underestimating the licensing relationship. "Royalty-free for non-commercial use" does not mean royalty-free for your commercial streaming product. The commercial license model is real, the per-viewer-month or per-GB or per-device fee is real, and it must be negotiated and budgeted before you commit. Several teams have built HESP proofs-of-concept on the free tier and only discovered the licensing scale-up shape when the project moved to production.
Pitfall 4: Assuming the IETF draft is a standard. It is not. draft-theo-hesp-06 is an expired individual informational submission. Treat it as a vendor technical reference, not as a stable interoperability contract. If your procurement requires "delivered over an IETF standard", HESP does not meet the requirement; LL-HLS, LL-DASH, and WebRTC do.
Pitfall 5: Forgetting iOS Safari's MSE history. HESP needs Media Source Extensions; iOS Safari only gained MSE on iPhone in iOS 17.1 (October 2023). Viewers on iOS 16 or earlier on iPhone have no HESP path at all. The Compatibility profile with HLS fallback is the only realistic answer.
Pitfall 6: Comparing latency numbers without the path detail. A HESP demo at 330 ms and a WebRTC demo at 280 ms and an LL-HLS deployment at 3 seconds are all correct on their respective configurations. The number that matters for your project is glass-to-glass on your encoder, your CDN, your player, your viewer geography. Insist on a live A/B test against your actual stack before committing to a protocol.
Pitfall 7: Mistaking the HESP Alliance for the IETF. The Alliance is a commercial consortium that promotes adoption, manages royalties, and certifies products. The IETF is the standards body that publishes RFCs. The Alliance does not have the standardisation authority of the IETF. HESP membership of the Alliance is not the same as HESP being an IETF standard.
Where Fora Soft Fits In
We have shipped HESP-aware delivery stacks in two verticals where the latency-and-scale intersection genuinely justified the licensing commitment: a Tier-2 European sports betting product where the live in-play markets close on a sub-second margin and the 30 to 80 thousand concurrent viewers per match made WebRTC uncompetitive on cost; and a multi-camera live-events platform for tier-1 motorsport where the 100-millisecond channel-change between camera angles is the product's distinguishing feature. In both cases the choice was made deliberately, with a clean-eyed view of the vendor-lock-in trade and the long-term licensing budget. Outside that intersection, our 2026 default for sub-second is WebRTC for bounded audiences and our 2026 default for "as low as possible while staying on CDN economics at large scale" is LL-HLS — we do not push HESP into projects where its single-vendor governance is a procurement risk.
What To Read Next
- WHEP: HTTP-Based Egress for WebRTC — the open-standard sub-second alternative for bounded audiences.
- LL-HLS in Depth: Parts, Preload Hints, Blocking Reload, Rendition Reports — the open-standard sub-five-second alternative at scale.
- Picking a Delivery Protocol in 2026 — the full decision tree across all modern delivery protocols.
CTA
Talk to a streaming engineer · See our case studies · Download the HESP evaluation checklist (PDF)
References
- draft-theo-hesp-06 — HESP - High Efficiency Streaming Protocol, P. Speelmans, Ed. (THEO Technologies), IETF Internet-Draft (individual submission), category Informational, published 17 April 2024, expired 19 October 2024. The canonical specification of HESP version 2. Every section reference in this article (§1 Introduction, §2 Protocol Overview, §2.2 Two Complementary Streams, §2.3 Object Model, §3 Manifest, §4 Initialization Stream, §5 Continuation Stream, §5.1.1 Maximum Gain Profile, §6 Timed Metadata, §7 Content Protection, §9 IANA, §10 Security) points at this draft.
- HESP Alliance — Official website, retrieved May 2026. The consortium governance, the membership roster, the certification programme, and the public licensing model description.
- HESP Alliance — Royalty Rates page, retrieved May 2026. The public statement of the three commercial royalty models (usage volume, user subscription, per device), the royalty-free non-commercial tier, the royalty-free stream-initiation tier, and the FRAND framing.
- HESP Alliance — FAQ page, retrieved May 2026. The public statements on Silver vs Gold membership and the USD 10 million revenue ceiling distinguishing Silver from Gold.
- High Efficiency Streaming Protocol Technical White Paper, THEO Technologies, 2021 (updated 2024). The white paper containing the 400 ms latency claim, the 100 ms zapping claim, and the 10-to-20-percent bandwidth-reduction claim against LL-HLS and CMAF-CTE. The benchmark methodology and the latency-budget tables are sourced from this document.
- RFC 8216 — HTTP Live Streaming, R. Pantos, W. May, IETF Standards Track, August 2017. The HLS specification HESP positions itself against on the latency floor.
- ISO/IEC 23000-19:2024 — CMAF Common Media Application Format, ISO/IEC. The CMAF object model that HESP's Continuation Stream and Initialization Stream are built on.
- ISO/IEC 23009-1:2022 — DASH MPEG-DASH, ISO/IEC. The DASH base specification HESP's manifest model is conceptually parallel to.
- Apple HLS Authoring Specification, revision 2025-09. The LL-HLS protocol revision HESP is compared against in production benchmarks. The September 2023 revision removed HTTP/2 server push from LL-HLS, which affects the LL-HLS vs HESP latency comparison.
- W3C Media Source Extensions, Candidate Recommendation 2024-11-05. The browser API HESP players use to drive the playback pipeline. iOS Safari only gained full MSE on iPhone in iOS 17.1 (October 2023), constraining HESP's iOS reachability.
- Gcore HESP-Ready Documentation and Service Page, retrieved May 2026. The Silver-member CDN's documentation for delivering HESP as a managed service.
- EZDRM — HESP DRM Solution, retrieved May 2026. The Silver-member DRM provider's documentation for CENC integration with HESP.
- THEO Technologies and Synamedia form HESP Alliance — press release, March 2020. The founding statement of the Alliance and the historical timeline (HESP introduced 2018, NAB 2019 demo, Alliance founded 2020).
- High Efficiency Streaming Protocol: End-to-end latency compared, S. Tielemans (THEO Technologies), LinkedIn engineering article, 2019. The earliest published latency comparison numbers between HESP and CMAF-CTE; the 330 ms achievable-baseline figure cited in this article is sourced here.
- High Efficiency Streaming Protocol: Bandwidth usage, S. Tielemans (THEO Technologies), LinkedIn engineering article, 2019. The 10-to-20-percent bandwidth-reduction claim methodology.
- HESP - High Efficiency Streaming Protocol — Wikipedia, retrieved May 2026. The community summary of HESP's history, governance, and protocol structure. Useful for orientation; the article followed primary sources where they disagreed.
