ProjectsLive
Sub-second live with WHIP and WHEP
Live auctions, Q&A and watch-alongs where a few seconds of delay is too much
Example design
- 01Go liveThe presenter's page asks the Worker to start the event. The Worker checks the presenter's role.
- 02Live inputThe Worker creates or reuses a Stream live input for the event and returns its WHIP URL.
- 03Publish over WHIPThe browser sends camera and microphone to Stream over WebRTC. No encoder software is involved.
- 04JoinA viewer opens the event page. The Worker checks access and returns the WHEP URL.
- 05Play over WHEPThe viewer's browser plays the stream over WebRTC, less than half a second behind the presenter.
- 06Bid or commentBids and chat go over a WebSocket to one Durable Object per event, which puts them in a single order.
- 07Event stateThe presenter and every viewer get the same state from the same object, so nobody sees bids in a different order.
- ifThe event needs a recordingStream does not yet record WebRTC broadcasts. If a recording is required, it is made separately, or the event uses an RTMPS or SRT input, which Stream records automatically at normal HLS latency.
The problem
HLS live usually runs several seconds behind, and low-latency HLS still runs a few. For a live auction, a watch-along with chat, or a Q&A where viewers react to what they see, the format does not work with that delay. WebRTC brings it under a second. Cloudflare Stream accepts WebRTC ingest over WHIP and plays it back over WHEP, so a presenter can broadcast from a browser without an encoder, and there is no media server to run.
What it uses
- Stream
- WHIP ingest and WHEP playback
- Workers
- Access checks and live input management
- Durable Objects
- One per event, holding bids, chat and event state
The decisions, and why
- ProtocolWHIP in, WHEP out
- Stream requires the two to be used together. An RTMP or SRT input cannot be played back over WHEP.
- CodecsH.264 Constrained Baseline, VP8 or VP9
- These are the codecs Stream accepts over WebRTC, and current browsers can send them.
- Event stateA Durable Object per event
- Bids need one order that everyone agrees on. A single object per event gives that without a database round trip per bid.
- RecordingSeparate, if required
- Stream does not record WebRTC broadcasts yet, so decide before the event whether you need a recording.
Limits to plan around
- Stream does not yet support recording or live HLS playback for WebRTC inputs.
- Simulcasting to other platforms is not supported for WebRTC inputs.
- Live viewer counts are not available for WebRTC, so audience figures come from your own telemetry.
What you get
- Presenter and viewer pages with WHIP and WHEP
- Worker for access and live inputs
- Durable Object for bids, chat and event state
- Load test at the expected audience size
- A rehearsed fallback to a standard-latency input
- Runbook for the day
Other projects
More video work on Cloudflare.
- Instant clips from a live streamViewers clip the moment they just saw and share it while the event is still on
- One live feed to many platformsSend one encoder feed to your own site and to YouTube, Twitch and others at once
- Serverless video platformUploads, encoding, captions and signed playback with no servers to run
- FFmpeg encoding on Cloudflare ContainersYour own ladder and packaging, started by an upload, served from R2
- Searchable video archiveFind the moment in hours of recordings by what was said
- Thumbnails and previews by URLHover previews, thumbnails and storyboards for a clip library, with no batch jobs
DRM solutions
Three corporate use cases, each with a Widevine demo that runs in your browser and checks what your device supports.
Talk about your video project
Tell us what you are building, or what is not working in the platform you have.
128 City Road, London, EC1V 2NX, United Kingdom
17420568
Registered in England and Wales