Web Real-Time Streaming (WebRTS) is a transport-agnostic framework designed to enable live streaming over the web with minimal latency. Unlike WebRTC—which requires a signaling server and peer-to-peer negotiation—WebRTS delivers media over standard HTTP infrastructure, making it compatible with global CDN deployments out of the box. Unlike HLS or MPEG-DASH, which are designed for reliable delivery at the cost of multi-second latency, WebRTS prioritizes staying at the live edge through adaptive frame skipping, dynamic playback rate control, and intelligent buffer management.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/CeeblueTV/wrts-client/llms.txt
Use this file to discover all available pages before exploring further.
Transport Layer
WebRTS is transport-agnostic by design, meaning the same media framing and latency mechanisms can run over any byte-oriented transport. The current implementation targets HTTP/2 as its primary transport.HTTP/2 and CDN Integration
HTTP/2’s multiplexing capability allows audio and video segment requests to be delivered over a single TCP connection simultaneously. This eliminates the per-request connection overhead of HTTP/1.1 HLS while remaining fully compatible with existing CDN infrastructure worldwide. Key advantages of HTTP/2 as the WebRTS transport:- Works with existing CDNs — no custom infrastructure or origin protocol changes required
- No special browser permissions — unlike WebRTC’s getUserMedia or TURN/STUN requirements, HTTP/2 requests use standard browser fetch APIs
- Multiplexing reduces overhead — audio and video segments share one connection rather than each opening their own
- Globally deployable — any CDN or origin server that supports HTTP/2 (or HTTP/1.1 as a fallback) can serve WebRTS streams
HTTP/3 / QUIC (Future Roadmap)
The WebRTS team plans to evaluate HTTP/3 (QUIC) as a transport option to unlock further performance gains, particularly for long-distance streaming scenarios. QUIC’s connection migration and reduced head-of-line blocking properties are well-suited to the unreliable-network use cases that WebRTS is already designed to handle. This evaluation will be pursued while preserving broad deployment compatibility.Contrast with WebRTC and HLS/DASH
| Feature | WebRTS | WebRTC | HLS / DASH |
|---|---|---|---|
| Transport | HTTP/2 (CDN-native) | UDP / DTLS (peer-to-peer) | HTTP/1.1 or HTTP/2 |
| Signaling required | No | Yes (SDP exchange) | No |
| CDN compatible | Yes | No (requires TURN/STUN) | Yes |
| Typical latency | < 500 ms | < 100 ms | 3–30 s |
| Frame skipping | Yes (adaptive) | Browser-managed | No |
| Bitrate adaptation | Yes (MBR) | Limited (browser) | Yes (ABR) |
Architecture Overview
A WebRTS stream flows from a media server to the browser through a small set of composable components:WSSource replaces HTTPAdaptiveSource:
Player class orchestrates both paths. Passing a ws:// or wss:// endpoint to player.start() automatically selects WSSource; an https:// or http:// endpoint selects HTTPAdaptiveSource.
Low-Latency Mechanisms
WebRTS achieves sub-second latency through four cooperating mechanisms. Each is described in detail in the Buffer Management guide.Buffer State Machine
The player continuously measures how much media is buffered ahead of the current playback position. It classifies this into four states —
NONE, LOW, OK, and HIGH — and uses these states to drive all other adaptation decisions.Dynamic Playback Rate
When the buffer grows too large (
HIGH state), playbackRate is gently increased up to 1.16× to drain the buffer and move closer to the live edge. When the buffer shrinks too far (LOW state), playbackRate is decreased to as low as 0.84× to slow consumption and allow the buffer to refill. In the OK state, playbackRate returns to exactly 1.0.Adaptive Bitrate (MBR)
When multiple quality renditions are available, the player switches to a lower video track when the buffer enters the
LOW state. It switches back up once the buffer recovers above the middle threshold and estimated bandwidth allows it.Frame Skipping (Partial Reliability)
When
player.reliable = false (the default) and the buffer is critically low or a stall is detected, HTTPAdaptiveSource aborts in-flight segment downloads and calculates the delay to the live edge. If the delay exceeds a sequence duration, the sequence number is incremented to skip that content. For the lowest-quality video rendition, only the first key frame of a segment may be downloaded to preserve visual updates without requiring full bandwidth.Why HTTP/2?
CDN Native
HTTP/2 is supported by every major CDN. WebRTS streams can be served from existing origin infrastructure without custom protocols or edge configurations.
No Browser Permissions
Fetching media over HTTP/2 uses the standard
fetch() API. No microphone, camera, or TURN/STUN permissions are required, and content policies are straightforward.Connection Efficiency
A single HTTP/2 connection multiplexes concurrent audio and video segment requests, reducing TCP connection overhead versus parallel HTTP/1.1 requests.
Standard Infrastructure
Firewalls, proxies, load balancers, and monitoring tools already understand HTTP. There are no new protocols to allowlist or inspect.
Use Cases
WebRTS is designed for applications where latency is a competitive differentiator and CDN scale is a requirement:- Live sports and events — viewers see goals, plays, and reactions within milliseconds of broadcast
- News and elections — breaking-news streams arrive at the live edge, not seconds behind
- Interactive streaming — presenters and audiences share a near-synchronous experience
- Remote monitoring — industrial or security camera feeds where real-time awareness matters
- Auction and trading platforms — time-critical visual information delivered at web scale
Buffer Management
How the buffer state machine, playback rate adaptation, and frame skipping work together to maintain live-edge playback.
RTS Format
The lightweight RTS container format used for real-time media delivery, including its packet types and LEB128 encoding.