REMB (Receiver Estimated Maximum Bitrate) is an older WebRTC congestion-control signal in which the receiver estimates how much bandwidth the path can carry and tells the sender, via an RTCP feedback message, to stay under that ceiling. The sender then adapts its encoder bitrate to avoid overflowing the link, which for audio mostly means it gives way to video under contention since voice needs little. REMB was the original bandwidth-estimation approach in libWebRTC and is now largely superseded by transport-wide congestion control (transport-cc), which moves the estimation to the sender for finer, faster reaction. You still encounter REMB in older stacks and as a fallback.

Book cover: Audio for Video, Volume 5 of the Fora Soft Video Engineering Handbook

The book · Volume 5 of 7

Audio for Video: A Complete Guide to Sound in Video Products: From Jitter Buffers and Lip Sync to Atmos, Quality Metrics, and Neural Codecs

REMB still shows up in older WebRTC stacks and SFUs, and mixing it with transport-wide congestion control leads to odd bitrate swings. This volume covers REMB in detail with bandwidth estimation, bitrate and topology decisions, jitter buffers and loss recovery, so you can reason about how audio bitrate reacts to the network. Written by Nikolay Sapunov, CEO at Fora Soft.

Read it on Amazon →Kindle & paperback · Fora Soft Video Engineering Handbook

Seeing bitrate swings in WebRTC calls tied to REMB congestion control?

Share call stats or logs and we will analyze REMB and congestion control behavior and recommend changes to your SFU or client setup. 250+ video products shipped since 2005.

Book a 30-min call →WhatsApp →Email us →