FAQs: Video FAQs

How E2EE video calls work in practice, from device authentication and group keys to SFrame frame encryption, SFU forwarding, and rekeying when people join or leave.

How simulcast lets one video call serve every viewer's bandwidth, what it costs the sender, and how it differs from SVC, transcoding, and multistreaming.

How WebRTC gets two devices behind different routers to connect, covering NAT, STUN, signaling, ICE hole punching, TURN relays, and the RTCPeerConnection API.

Choppy call audio is usually jitter, not bandwidth. See how a jitter buffer reorders and paces packets, how it picks its size, and how it conceals lost packets.

Frame rate controls one specific property of video, how densely motion gets sampled over time, and most decisions around it get easier once you know which one. This covers what frame rate measures, how it differs from resolution and bitrate, how to pick a rate, and the bugs that come from treating fps as one uniform number.

Echo happens because every device on a call plays and records audio at once, and the delay added by network transit and buffering is what makes the overlap audible instead of unnoticeable. This covers how acoustic echo cancellation works, WebRTC's default AEC3 pipeline, why users still hear echo, and how to fix it.

WebRTC promises a direct connection between two devices, and the internet makes that hard. ICE is the part of the stack that closes the gap, discovering candidate addresses, exchanging them, and testing pairs until it finds one that actually works. This covers how ICE works, STUN vs. TURN, Trickle ICE, and how to debug calls that won't connect.

Large group video calls stay under a few hundred milliseconds by moving the work onto the server. Here's how SFUs, WebRTC, and simulcast keep latency low.