Why live video still feels delayed

Live streaming technology has not kept pace with what creators and viewers now expect. For developers, the gap between what "live" should mean and what mainstream protocols actually deliver has become a recurring frustration.

Viewers increasingly treat "live" as synonymous with "real-time." Use cases like live sports betting, interactive Q&A sessions, and remote participation in auctions or events require the remote audience to feel synchronized with what is happening on screen. Yet HLS and DASH, the dominant delivery standards, routinely introduce 10 or more seconds of latency. LL-HLS and LL-DASH reduce that to roughly five seconds, but only by adapting the same segmented, HTTP-based architecture. Mini video clips sent over TCP are fundamentally unsuited to true real-time playback.

Broadcasters face a separate set of constraints. RTMP, the long-standing broadcast protocol, cannot be used from a browser, and its reliance on TCP means it struggles under even minor network disruption when transmitting from a mobile connection. SRT improves on RTMP but still leaves creators without a web-native path to go live. For developers, building native RTMP broadcasting clients typically requires working in lower-level languages like C or Rust, putting live video features out of reach for many front-end teams.

New standards for WebRTC ingestion and delivery

WebRTC has long been the protocol behind real-time video calling in browsers, but it historically lacked standardized approaches for one-to-many streaming. Broadcasters had no standard equivalent to RTMP for sending media, and viewers had no standard equivalent to HLS or DASH for requesting and receiving it. That gap pushed developers toward tightly coupled, vendor-specific SDKs that are difficult to migrate away from.

Two emerging IETF drafts aim to close that gap:

  • WHIP (WebRTC-HTTP Ingestion Protocol), which standardizes how broadcasters send media to a service.
  • WHEP (WebRTC-HTTP Egress Protocol), which standardizes how viewers discover and receive a live stream.

Cloudflare Stream now supports both in open beta. Broadcasters using WHIP and viewers using WHEP can connect through Cloudflare's global network without touching any Cloudflare-specific SDK. The implementation runs on Cloudflare's developer platform: Workers and Durable Objects direct broadcasters and viewers to the point of presence closest to them, routing the video over the network with no centralized state and sub-second latency.

Because this all runs on infrastructure that is already within 50ms of 95% of the world's Internet-connected population, pricing does not have to carry a WebRTC premium. Once generally available, streaming over WebRTC will cost $1 per 1,000 minutes delivered, the same as HLS or DASH delivery on the service.

Browser-based broadcasting in about 100 lines of JavaScript

The practical consequence of a standards-based approach is that adding live broadcasting to a website no longer requires specialized video protocol knowledge. A browser can capture camera and microphone input and send it directly to a live input created in the Cloudflare dashboard. An example WHIP client shows the flow in roughly 100 lines of browser-native JavaScript, with zero dependencies on third-party libraries.

Adoption of WHIP is already moving. It has been added to Gstreamer, and an open-source JavaScript client implementation exists as well. Cloudflare plans to support the full WHIP specification as it matures, including Trickle ICE for fast NAT traversal.

Playback follows the same pattern. A WHEP client, also written without dependencies, can connect to a live input from a browser and render the stream with sub-second latency. WHEP is at an earlier stage than WHIP—the draft was published in July—but the community has already produced open-source clients in JavaScript and C.

Availability

WebRTC streaming is available now in open beta as an integrated feature of Cloudflare Stream. Developers can create a live input from the Cloudflare dashboard and start experimenting with both ingestion and playback immediately. After the beta period, pricing will match the rest of the Stream product, based only on minutes of video delivered and minutes stored.