Adaptive Bitrate

Половина участников Zoom-звонка - на мобильных с нестабильной сетью. Как показывать HD видео одним и не замораживать экран других?

• **Google Meet + VP9 SVC** - один поток с иерархическими слоями вместо 3 simulcast потоков, экономия CPU браузера 30%, поддержка 500 участников в enterprise tier
• **Twilio Video simulcast** - три параллельных потока (150/600/2000 Kbps), SFU выбирает нужный для каждого получателя, документированное снижение freeze rate с 8% до 0.9%
• **Discord Go Live** - адаптивный битрейт для game streaming: при потере сети переключается с 720p60 на 360p30 за <200ms через Transport-CC feedback loop

Bandwidth Estimation

Чтобы выбрать правильное качество видео, браузер должен знать, сколько полосы доступно прямо сейчас. WebRTC использует два алгоритма оценки: **REMB** (Receiver Estimated Maximum Bitrate) - получатель измеряет межпакетные задержки и сообщает отправителю через RTCP, и **Transport-CC** (Transport-Wide Congestion Control) - более точный, получатель возвращает timestamp каждого пакета, отправитель сам считает bandwidth.

Google's **GCC** (Google Congestion Control) - алгоритм, который используют Chrome и большинство SFU. Он анализирует trend межпакетных задержек: если задержки растут - сеть перегружена, снижаем bitrate на 15%. Если стабильны - плавно поднимаем. Реакция на перегрузку быстрая (100ms), восстановление медленное (8 секунд) - чтобы не вызвать новую перегрузку.

Google Meet переключился с REMB на Transport-CC в 2018 году. Точность оценки выросла с ±30% до ±8%, количество заморозок видео снизилось на 40% по внутренним метрикам.

Simulcast Layers

**Simulcast** - отправитель (браузер или мобильное приложение) кодирует один и тот же видеопоток в нескольких качествах одновременно и отправляет все три на SFU. SFU выбирает, какой слой форвардить конкретному получателю в зависимости от его доступной полосы. Это ключевой механизм адаптации в modern video conferencing.

Стандартная конфигурация: три spatial слоя - **f** (full, 1080p 2Mbps), **h** (half, 540p 600Kbps), **q** (quarter, 270p 150Kbps). Пользователь с 4G получает f-слой, пользователь на slow WiFi - q-слой. SFU переключается между слоями на keyframe boundary чтобы не вызывать артефакты.

Twilio Video документирует: при simulcast CPU на браузере растёт на 15-25% (кодирование трёх потоков), но исчезают заморозки у участников с плохой сетью. В enterprise сценарии - worth it. На мобильном - simulcast часто ограничивают до 2 слоёв.

Scalable Video Coding (SVC)

**SVC** (Scalable Video Coding) - альтернатива simulcast. Вместо трёх независимых потоков отправляется один поток с иерархическими слоями. **Base layer** (270p) самодостаточен. **Enhancement layers** добавляют качество, но зависят от base layer. SFU может «отрезать» enhancement layers прямо в сети без перекодирования.

VP9 и AV1 поддерживают spatial SVC нативно. H.264 SVC (через SVC расширение) распространён меньше. Google Meet использует VP9 SVC начиная с 2020 года: один поток от отправителя вместо трёх при simulcast, экономия CPU на отправляющей стороне ~30%. SFU дропает пакеты enhancement слоёв для участников с плохой сетью.

Google Meet с VP9 SVC обслуживает до 500 участников в Google Workspace Enterprise. При simulcast 500 участников каждый слал бы 3 потока = 1500 потоков на SFU. С SVC - 500 потоков. Разница в инфраструктурных затратах - 3x.

Quality Adaptation

**Quality adaptation** - логика на SFU, которая принимает решение: какой simulcast слой или SVC layer форвардить каждому получателю в каждый момент. Входные данные: Transport-CC feedback от получателя, размер изображения на экране получателя, приоритет спикера (активный говорящий получает больше битрейта).

**Bandwidth allocation** в Zoom: активный спикер получает 70% доступной полосы, остальные участники делят 30%. При изменении спикера - перераспределение за 200ms. В Google Meet иначе: все видео равноправны, но thumbnail-размер определяет запрошенный слой. Чем меньше плитка на экране - тем ниже слой форвардируется.

Livekit (open-source SFU) публикует данные: при правильной quality adaptation 95-й перцентиль video freeze rate на плохих сетях снижается с 8% до 1.2%. Ключевой параметр - скорость реакции на изменение bandwidth: слишком быстро = частые артефакты, слишком медленно = длинные заморозки.

Итоги

• **Bandwidth estimation** (Transport-CC + GCC) - браузер непрерывно измеряет доступную полосу через RTCP feedback и корректирует битрейт
• **Simulcast** - три независимых потока от отправителя, SFU форвардирует нужный; **SVC** - один иерархический поток, SFU дропает enhancement layers
• **Quality adaptation** на SFU распределяет полосу по приоритетам: активный спикер получает больше, переключение слоёв только на keyframe

Связанные темы

Adaptive bitrate строится поверх WebRTC инфраструктуры и влияет на всю систему:

• SFU Architecture — SFU - центральный элемент ABR: принимает все simulcast слои и форвардирует нужный каждому получателю
• WebRTC масштабирование — SVC сокращает количество потоков на SFU в 3x - прямое влияние на горизонтальное масштабирование
• Network Protocols — Transport-CC работает поверх RTCP, GCC реализует AIMD (Additive Increase Multiplicative Decrease)

Вопросы для размышления

• Google Meet использует VP9 SVC, Zoom - H.264 simulcast. Какой подход даст меньше CPU нагрузки на мобильных устройствах при 10 участниках - и почему это не однозначный выбор?
• Transport-CC GCC снижает bitrate на 15% при первых признаках перегрузки. Как это взаимодействует с TCP Slow Start, если под WebRTC есть TCP-туннель?
• Разработать алгоритм quality adaptation для стриминга gaming контента: чем он отличался бы от алгоритма для video conferencing с точки зрения приоритетов?

Связанные уроки

• net-24-http2-http3