Protocol comparison for live contribution — based on RFC 9725 (WHIP), RFC 8825 (WebRTC), and QuicFeed v2 test results
WebRTC WHIP (WebRTC-HTTP Ingestion Protocol) is increasingly used for live ingest — OBS ships WHIP output, Cloudflare Stream accepts WHIP ingest — but its architecture targets a fundamentally different problem than QuicFeed's contribution/backhaul design.
The most important protocol difference. GCC (Google Congestion Control) is a delay-based hybrid controller designed for interactive video calls. LiveCC is a loss-only controller designed for stable contribution feeds.
| WebRTC (GCC) | QuicFeed (LiveCC) | |
|---|---|---|
| Algorithm class | Delay + loss hybrid | Loss-only |
| Jitter response | Interprets delay variation as congestion; reduces rate | Ignores jitter entirely — only reacts to actual packet loss |
| Loss response | Proportional rate reduction | 0.85x multiplicative decrease (gentler than Cubic 0.7x) |
| Bandwidth estimation | Dynamic — REMB/Transport-CC feedback | Static --max-bitrate + BDP floor + RX buffer feedback |
| CWND floor | None — can drive bitrate to near-zero | target_rate * smoothed_rtt — never drops below target |
| Steady-state stability | Oscillates — delay-based probing causes rate swings | Stable — holds target rate unless actual loss occurs |
Why this matters for contribution: GCC would back off under the same jitter that caused Cubic to collapse in v1 testing. QuicFeed v2 Phase 4 (50ms delay + 20ms jitter): LiveCC held 5.2 Mbps and delivered 353 files, while Cubic collapsed to 1.3 Mbps / 117 files. GCC interprets inter-arrival jitter as congestion and would similarly reduce sending rate.
| WebRTC | QuicFeed | |
|---|---|---|
| Transport | RTP/RTCP over DTLS-SRTP over UDP | QUIC (RFC 9000) over UDP |
| Framing | 1200-byte RTP packets | Complete CMAF segments per QUIC stream |
| Reliability | Partial — NACK + FEC; some packets may be permanently lost | Full — QUIC guarantees per-stream reliable delivery |
| HoL blocking | Partial — BUNDLE shares one DTLS association | None — independent QUIC streams |
| Flow control | Periodic RTCP receiver reports | QUIC per-stream + connection-level (per-packet ACKs) |
| WebRTC | QuicFeed | |
|---|---|---|
| Media unit | Individual NAL units (frames) | Complete CMAF segments (1s) or LL-HLS parts |
| Container | Raw codec payloads in RTP | ISO BMFF (fMP4) with full metadata |
| Codec support | Limited to codecs with RTP packetization specs | Any codec ISO BMFF supports (including H.265/HEVC) |
| Downstream | Requires remuxing for HLS/DASH delivery | CDN-native — CMAF segments are directly HLS/DASH-compatible |
| Stream typing | SDP media descriptions | Wire format v2 StreamType byte |
| WebRTC (WHIP) | QuicFeed | |
|---|---|---|
| Signaling | HTTP POST of SDP offer/answer | Direct QUIC connection + worker auth API |
| ICE gathering | Required — 100ms-2s for STUN/TURN candidates | Not needed — TX connects directly to known RX |
| Total setup | 500ms-3s (ICE + DTLS) | 1-RTT (first connect) or 0-RTT (resumption) |
| Reconnection | Full ICE + DTLS re-negotiation | 0-RTT — data on first packet |
| WebRTC | QuicFeed | |
|---|---|---|
| Theoretical floor | ~50-200ms (frame-level) | ~33ms per part (fragment-level with LL-HLS/L3D-DASH) |
| Media unit | Individual NAL units (~33ms at 30fps) | Individual CMAF fragments (~33ms at cdur=0.0333) |
| Delivery model | RTP packets as encoded | Each segment = 1 QUIC stream; QUIC delivers bytes reliably and in order, so the RX writes individual fragments as LL-HLS parts as they arrive within the stream |
| Jitter buffer | Adaptive — dynamic buffer depth | TSBPD — fixed latency via --latency |
| Late arrivals | Adaptive playout; may skip frames | Absolute delay floor — --max-transfer-time kills slow streams via STOP_SENDING; --latency drops files past playout deadline (TLPKTDROP) |
| Glass-to-glass | 200ms-1s typical (interactive) | Sub-second with LL-HLS parts (contribution) |
QuicFeed's latency floor is not segment-bounded. Each 1s segment is its own QUIC stream, but QUIC delivers bytes reliably and in order within each stream. With 30 fragments per segment (IDR on the first fragment), the RX can parse and write each ~33ms fragment as an LL-HLS part file (part-v-000003-0002.m4s) as soon as it arrives, updating the playlist immediately. An LL-HLS or L3D-DASH player can begin fetching parts as they appear — it does not wait for a full segment. This puts QuicFeed's per-fragment latency floor in the same range as WebRTC's per-frame delivery, while retaining full QUIC reliability and CDN-native CMAF output.
| WebRTC | QuicFeed | |
|---|---|---|
| Media encryption | SRTP (AES-128/256-CM) | TLS 1.3 built into QUIC |
| What's encrypted | RTP payload only — headers are visible | Nearly everything — only connection ID visible |
| Header protection | None — RTP headers in the clear | QUIC header protection — even packet numbers encrypted |
| Key rotation | SRTP re-keying via DTLS renegotiation | TLS 1.3 key update (seamless) |
| WebRTC | QuicFeed | |
|---|---|---|
| Primary mechanism | NACK + Flexible FEC (5-20% bandwidth overhead) | QUIC ACK-based retransmission (per-stream) |
| Delivery guarantee | Partial — some packets may be permanently lost | Full — every segment delivered or killed early |
| FEC overhead | 5-20% of bandwidth | 0% — no FEC needed |
v2 Phase 4: 62,357 lost packets triggered retransmission, but all 353 files were delivered intact with zero errors. LiveCC's 0.85x backoff kept enough bandwidth for retransmits.
| WebRTC | QuicFeed | |
|---|---|---|
| Connection identity | ICE candidate pair (IP:port) | QUIC Connection ID (independent of IP/port) |
| Network migration | ICE restart — media interruption | Transparent — same connection continues on new path |
| Migration latency | 500ms-3s | Near-zero |
| Reconnection | Full setup (WHIP POST + ICE + DTLS) | 0-RTT — cached session ticket |
| WebRTC | QuicFeed | |
|---|---|---|
| NAT traversal | Full — ICE + STUN + TURN | None needed — TX connects outbound to known RX |
| Infrastructure | STUN + TURN servers required | None — direct connection |
| Deployment model | Works between any two endpoints | RX must have a reachable address |
This is WebRTC's clearest advantage. For contribution/backhaul, NAT traversal is unnecessary — the RX is always a known server with a reachable address.
| WebRTC | QuicFeed | |
|---|---|---|
| Video codecs | H.264, VP8, VP9, AV1 (each needs RTP packetization spec) | Any codec ISO BMFF supports — including H.265/HEVC |
| Audio codecs | Opus (mandatory), G.711, limited AAC | AAC, Opus, AC-3, E-AC-3 |
| H.265/HEVC | Limited — no standardized RTP packetization in most stacks | Natively supported |
| Container metadata | None — raw codec payloads | Full ISO BMFF metadata |
H.265/HEVC delivers equivalent quality at ~40% lower bitrate than H.264. QuicFeed carries HEVC natively in ISO BMFF with no protocol-level changes needed.
QuicFeed and WHIP are designed for fundamentally different problems:
| Feature Area | Advantage | Reasoning |
|---|---|---|
| Congestion control | QuicFeed | LiveCC loss-only + BDP floor vs GCC delay-based oscillation |
| Transport reliability | QuicFeed | Full per-stream reliability vs partial NACK+FEC |
| HoL blocking | QuicFeed | Independent QUIC streams vs BUNDLE sharing one DTLS |
| Connection setup | QuicFeed | 1-RTT / 0-RTT vs ICE+DTLS (500ms-3s) |
| Encryption | QuicFeed | Full header protection vs exposed RTP headers |
| Connection migration | QuicFeed | Transparent via CIDs vs ICE restart |
| CDN compatibility | QuicFeed | CMAF segments are HLS/DASH-native |
| Codec flexibility | QuicFeed | ISO BMFF carries any codec including HEVC |
| Loss recovery | QuicFeed | 0% FEC overhead vs 5-20% |
| Absolute delay floor | QuicFeed | --max-transfer-time + --latency enforce an absolute delay floor — no segment stalls the pipeline beyond the deadline |
| Receiver health | QuicFeed | RX buffer feedback via QUIC datagrams 1/sec |
| Minimum latency | Comparable | WebRTC: frame-level ~33ms. QuicFeed: fragment-level ~33ms — RX writes parts as fragments arrive within each QUIC stream |
| NAT traversal | WebRTC | ICE/STUN/TURN vs requires reachable RX |
| Dynamic bandwidth | WebRTC | GCC adapts to unknown capacity |
QuicFeed advantages: 11 areas. Comparable: 1 area (minimum latency). WebRTC advantages: 2 areas (NAT traversal, dynamic bandwidth estimation).
For contribution/backhaul — known sender, known receiver, known bitrate, impaired but sufficient network — QuicFeed's design is better aligned. QUIC's reliable ordered delivery within each stream lets the RX write ~33ms LL-HLS parts as fragments arrive, achieving per-fragment latency comparable to WebRTC's per-frame delivery — while retaining full QUIC reliability, CDN-native CMAF output, and LiveCC throughput stability under jitter. 0-RTT and connection migration minimize disruption.
For interactive ingest — unknown endpoints, unknown bandwidth, NAT traversal required — WHIP/WebRTC is the right tool.
The protocols are complementary, not competing. A production pipeline might use WHIP for browser-based ingest to a cloud media server, then QuicFeed for contribution backhaul from that server to the CDN origin.