WebRTC Low-Latency Live Streaming: WHEP Playback

The host reads out a viewer’s name and the audience sees it half a beat late; the surveillance feed trails reality by a dozen seconds; the auctioneer’s hammer lands after the bids close — in these scenes, HLS’s 5–30 second latency is a hard fail. For sub-second end-to-end there is exactly industry answer: WebRTC. This article covers ZWPlayer’s WebRTC playback — standard WHEP signaling plus three private cloud protocols, with an rtc:// URL that just plays.

The Latency Ladder: Why It Must Be WebRTC

Latency ladder and WHEP path Figure 1: mainstream live protocols by latency, and the WHEP playback path

  • HLS/DASH (5–30 s): the segment+playlist design buys stability; latency is structural — longer segments, more latency, and it doesn’t compress;
  • LL-HLS (2–5 s): partial segments and blocking requests trade complexity for latency, with a floor still in whole seconds;
  • WebRTC (sub-second): a transport built for real-time communication (SRTP + congestion control + jitter buffers) — end-to-end latency naturally lands in the hundreds of milliseconds.

One-line rule: tolerate 5 seconds → HLS (stable, CDN-friendly); don’t → WebRTC.

WHEP: WebRTC Pull, Standardized

WebRTC playback used to be expensive because of signaling — every streaming server had its own SDP exchange, and every player its own glue. WHEP (WebRTC-HTTP Egress Protocol) standardizes the pull-side signaling as plain HTTP, and mainstream servers (SRS, ZLMediaKit, mediamtx) support it.

ZWPlayer ships a WHEP client; playback is just a URL:

new ZWPlayer({
  playerElm: 'player',
  url: 'rtc://your-server.com:1985/rtc/v1/whep/?app=live&stream=lesson01',
  // or pass any HTTP URL containing /whep/
});

Publishers (OBS, drones, conferencing systems) push via WHIP; viewers pull via WHEP in ZWPlayer — a standardized end-to-end chain; switching server vendors costs nothing.

Private Cloud Protocols: ARTC / TRTC / BRTC

Chinese clouds run their own ultra-low-latency protocols. ZWPlayer supports all three natively:

Protocol Vendor URL prefix
ARTC Alibaba Cloud artc://
TRTC Tencent Cloud trtc://
BRTC Baidu AI Cloud brtc://

If you already run a cloud’s low-latency product, swap the URL prefix and hand it to ZWPlayer — no vendor SDK in your page. The player handles signaling and transport internally, which means:

  • page weight doesn’t balloon by megabytes of SDK;
  • changing clouds is a URL-prefix change, zero player code changes;
  • multi-cloud routing (region A on vendor, region B on another) works in a single page.

Field Scenarios

  • E-commerce live: “3, 2, 1, link drops” must land on every screen at — sub-second latency converts;
  • Remote appraisal / auctions: a trailing hammer breaks the process;
  • Scenic slow-TV: construction sites and scenic views with WebRTC feel live (pair with VR panorama for panoramic live);
  • Co-streaming: low latency is the floor of usable interaction.

Deployment Notes

  • Servers: self-host SRS or ZLMediaKit (both speak WHIP/WHEP); on cloud, use the vendor’s low-latency product directly;
  • HTTPS: browsers gate WebRTC’s full capabilities behind secure contexts (same as autoplay and capture policies);
  • CDN and scale: WebRTC distribution costs more than HLS — a common architecture is “WebRTC main + HLS fallback”, with ZWPlayer’s multi-bitrate handling tier switching;
  • Autoplay: audible autoplay gets blocked — ZWPlayer probes muted autoplay with in-WeChat fallbacks, but live pages should still start muted.