Live Media Over QUIC
summary
Twitch builds Warp and runs it in production for distribution while Meta uses RUSH for ingest, both built on QUIC to replace TCP's head‑of‑line limits. The implemented approach maps codec dependencies to the network by delivering frames in decode order on separate QUIC streams, prioritizing audio and newest video, starving older streams instead of blocking, and remaining CMAF/HLS/DASH compatible so existing segments and encoders work and players can fall back to HTTP when QUIC is unavailable. A Media over QUIC working group is chartered to standardize it.
AI-written summary · about
chapters (17)
- 0:00Live media over QUIC intro
- 1:11HLS DASH RTMP problems
- 2:34WebRTC shortfalls for live media
- 3:37Why QUIC now
- 4:39QUIC protocol features
- 6:01QUIC stream independence
- 7:03Replacing TCP with QUIC
- 8:07Latency sources in live media
- 10:13Buffer bloat congestion control
- 11:15Video encoding structures
- 13:03Encoding mapped to QUIC streams
- 14:29Prioritizing audio video in WARP
- 15:54Variable latency UX
- 16:39Backward compatibility HLS DASH
- 17:42Alternative approaches RUSH
- 18:02Next steps Media over QUIC WG
- 18:44Q&A contact
related talks
21mReplacing WebRTC with Media over QUIC
38mWebRTC and QUIC: how hard can it be?
22mQ&A Session 2 – Bharat Parekh
43mDASH and Media-over-QUIC Transport Face-Off: Performance Showdown at Low Latency
19mThe Future With QUIC
54mQUIC illustrated
18mImproving Transfer Times in the Backbone Network Using QUIC Jump Start
34mQUIC and HTTP/3: Too Big to Fail?!