Beyond P2P: Video Routing in WebRTC
summary
WebRTC conferencing scales best with a router (SFU) that forwards layered streams instead of an MCU decoding and re‑encoding every feed; MCUs incur heavy CPU and unavoidable mixing latency while SFUs prioritize bandwidth. Tests with Jitsi-style routing show 1,000 streams producing about 500 Mbps / 20% CPU on a single bare‑metal box. Current practical approach uses simulcast via SDP (Chrome already generates separate layers; Firefox is following) and routers implement Chrome’s bandwidth estimation to pick layers per client.
AI-written summary · about
chapters (8)
- 0:00Intro
- 1:20Security
- 4:30P2P Mesh
- 7:55simulcast scalable video coding
- 11:05video routing
- 12:25simulcast
- 14:05Temporal
- 16:10Questions
related talks
22mWebRTC: Connecting Embedded, Mobile and Desktop with the Lowest Latencies
46mHow we deliver 1Tbps of video with our WebRTC peer-to-peer network
30mJitsi Videobridge: the state of the art SFU that powers Jitsi Meet
20mDecentralizing Video Streaming
41mServers for WebRTC: It is not all Peer to Peer
32mWebRTC Update
20mSharing is Caring: build a peer-to-peer network with WebRTC
43mThe unstoppable secret superpower of WebRTC