TWCC — серверная реализация адаптивного WebTRC при вещании на большую аудиторию

02.08.2022

9мин. чтения

Для решения задач в области видеозвонков, телемедицины, удаленного обучения, а именно для передачи видео с ультранизкой задержкой, используются решения из категории RTC, в частности WebRTC. WebRTC — это набор протоколов, разработанный для передачи зашифрованного видео в реальном времени по принципу peer-to-peer. Транспортный уровень WebRTC может быть основан на протоколах TCP/UDP. Кроме того, используется протокол RTP/RTCP для упаковки медиа данных, который поддерживает как встроенные механизмы, например RR/SR, NACK, PLI, FIR, FEC, REMB, так и расширения, позволяющие добавлять дополнительные возможности по контролю за передачей данных.

В этой статье мы расскажем о том, как мы используем вышеуказанные механизмы для передачи видео с адаптивным битрейтом.

Содержание:

Какая задача появилась перед нами, что это дает клиентам {#twcc-task}
Какие инструменты дает стандарт для разработчиков {#twcc-instruments}
- Изначальная версия
- Современная реализация
Чем наша реализация отличается от схемы “браузер-браузер” {#twcc-difference}
Как это работает
Как тестировали
- Инструменты
- Тесткейсы
Как делать нельзя
Как попробовать

Какая задача появилась перед нами, что это дает клиентам

В процессе передачи видео состояние сети может меняться как в сторону увеличения пропускной способности, так и в сторону её уменьшения. В WebRTC есть встроенные peer-to-peer механизмы, которые сообщают источнику о том, что видео получателю не доходит и надо понизить битрейт, или же наоборот, пропускная способность увеличилась и битрейт можно повысить.

При клиент-серверном взаимодействии нет технической возможности кодировать видео индивидуально под каждого клиента, и нужно переключаться между фиксированными качествами видео, которые заранее настроены на транскодере. Мы научились пользоваться механизмами из мира peer-to-peer для клиент-серверного взаимодействия и динамического изменения битрейта видео потока.

Таким образом, участник видеообмена, построенного с применением этого подхода, получает доступ к видео при абсолютно разных характеристиках сети, как исходных, так и изменяющихся во времени, например при использовании мобильной связи. Этот доступ осуществляется без буферизации и задержки воспроизведения.

Какие инструменты дает стандарт для разработчиков

Для оценки загруженности сети и текущей пропускной способности используются алгоритмы, которые измеряют задержки и потери пакетов и, на основании этих измерений, оценивают доступный битрейт полосы пропускания.

Изначальная версия

Изначальная версия оценки пропускной способности была основана на встроенной в браузер реализации алгоритма GCC (Google Congestion Control). Принимающая сторона подсчитывает информацию об RTP пакетах, включая количество потеряных пакетов. Далее, оценивается задержка времени прибытия между последовательными пакетами и вычисляется значение REMB (Receiver Estimated Maximum Bitrate). Формируются RR (Receiver Report) RTCP пакеты с информацией о REMB и количестве потерянных пакетов и пересылаются обратно на отправляющую сторону. Отправляющая сторона, в свою очередь, принимает RR RTCP сообщения и корректирует исходящий битрейт видеопотока.

GCC

Современная реализация

Современная реализация — это использование RTP расширения TWCC (Transport Wide Congestion Control).

В этом случае принимающая сторона возвращает специальным RTCP сообщением на отправляющую сторону время прибытия каждого пакета. Отправляющая сторона реализует алгоритм GCC или его аналог на своей стороне, измеряет задержки между прибытиями пакетов, а также идентифицирует потерянные и опоздавшие пакеты. При частом обмене такой информацией отправитель имеет возможность быстро адаптироваться к изменениям условий сети и корректировать характеристики исходящего видеопотока тем или иным способом.

На сегодняшний момент алгоритм, использующий TWCC, является лучшим выбором, поскольку он предоставляет отправляющей стороне большой набор данных для оценки реальных условий сети:

почти мгновенную информацию о потере пакетов, вплоть до индивидуальных пакетов;
точный битрейт отправки;
точный битрейт получения;
измерение джиттера;
разницу между задержками отправки и получения;
описание того, как сеть справляется с волнообразной или стабильной пропускной способностью.

В изначальном механизме оценки пропускной способности такие данные скрыты внутри браузерной реализации алгоритма GCC.

Также плюсом является сосредоточенность всей логики управления и контроля за видеопотоком на отправляющей стороне, что позволяет облегчить разработку и быстрее внедрять новые алгоритмы и решения, не заботясь об их поддержке на клиентской стороне.

Чем наша реализация отличается от схемы “браузер-браузер”

Браузерная реализация может использовать различные варианты алгоритмов GCC для управления видео-кодером таким образом, чтобы битрейт видеопотока был максимально приближен к величине доступной полосы пропускания для обеспечения максимального качества видео в каждый момент времени. То есть при общении “один на один” браузеры могут контролировать битрейт плавно, с маленьким шагом, например, по 50 кбит/с.

В нашем же случае есть несколько предопределенных вариантов битрейтов с которым видео было заранее закодировано. Следовательно, переключение возможно только между фиксированными битрейтами (дорожками). Шаг между дорожками может быть достаточно велик и для реализации такого решения нужно определить, что полоса пропускания достаточно велика для переключения на более высокий битрейт.

Применяя изначальную REMB реализацию механизма оценки состояния сети мы столкнулись с медленным ростом показателя оценки величины полосы пропускания со стороны браузера. Особенно это заметно на видео, в которых нет больших keyframes, например на записях с web-камер, где нет особой динамики и изменения фона.

Из-за особенностей кодирования видео исходящий битрейт не всегда равен указанному и зависит от кодируемого кадра и настроек кодировщика. Например, битрейт текущей проигрываемой дорожки 400 кбит/с, а следующей — 1300 кбит/с. Отправитель, при указанном битрейте в 400 кбит/с, может выдавать данные со скоростью 100 кбит/с, что приводит к снижению оценки пропускной способности на стороне получателя. Время роста оценки битрейта для переключения с одной дорожки на другую может длиться до 10 минут, а в каких-то случаях так и не достигать нужной величины.

Подобные проблемы возникают и в случае кратковременной потери связи, когда из-за роста числа потерянных пакетов выбирается видеодорожка с более низким битрейтом. Возникает момент, когда реальная пропускная способность восстановилась до изначального уровня, а оценка REMB не позволяет быстро вернуться к видеодорожке лучшего качества. На изображении ниже можно увидеть подобную ситуацию. Была кратковременная потеря связи с ростом packetLoss и nackCount. Связь восстановилась, и можно наблюдать рост показателя REMB.

Как это работает

Решения подобной задачи переключения между фиксированными битрейтами вместо управления кодером существуют (chromium, jitsi-videobridge), и их базовый принцип в общих чертах одинаков:

Используя механизм TWCC, периодически отправлять принимающей стороне набор пакетов для тестирования определенного битрейта.
Получать информацию о задержках по этим пакетам.
Вычислять реальный битрейт, с которым эти пакеты были отправлены и приняты.
Переключиться на видеодорожку с более высоким битрейтом, если реальный измеренный битрейт достаточно велик.

Разница заключается в определении ответов на следующие вопросы:

когда необходимо тестирование полосы пропускания,
как происходит выбор битрейта для тестирования,
что используется в качестве тестовых пакетов,
как анализируется и применяется значение измеренного битрейта.

В нашем случае в качестве тестовых пакетов используются payload пакеты из очереди отправки. Для тестирования полосы пропускания с битрейтом, превышающим битрейт текущей видео дорожки, периодически из очереди отправки выбирается набор пакетов с общим объемом равным величине тестируемого битрейта. Пакеты из набора отправляются по несколько штук таким образом, чтобы весь набор был отправлен со скоростью тестируемого битрейта. Получив информацию о времени прибытия тестовых пакетов, вычисляем битрейт и усредняем по EMA со значением предыдущего измерения. Увеличиваем значение тестируемого битрейта и повторяем процедуру. Когда максимальное значение измеренного битрейта превышает величину битрейта следующей по качеству дорожки на 10 процентов, происходит переключение на эту дорожку.

У подхода с использованием только payload пакетов есть плюсы и минусы:

Плюсы:

Мы не генерируем избыточный траффик, а отправляем только исходные payload пакеты.

Минусы:

Бывают ситуации, в которых общего размера пакетов для видеопотока с низким битрейтом, находящихся в очереди отправки, может не хватить для тестирования достаточно высокого битрейта.
В отправку пакетов вносится неравномерность, которая может влиять на величину jitter.

Дальнейшие шаги по улучшению решения видятся следующими:

Воспользоваться существующими решениями и использовать в качестве дополнительных тестовых пакетов пакеты из списка RTX и/или “пустые” padding пакеты. Для этого нужно выполнять упаковку видео кадров в RTP пакеты и выполнять SRTP кодирование непосредственно перед отправкой пакетов на принимающую сторону, чтобы была возможность добавить дополнительный пакет, не нарушая RTP последовательность.
Стоит отправлять тестовые пакеты в те моменты, когда полоса пропускания используется слабо. Использовать при этом так называемый ALR детектор, который измеряет размер отправленных данных и сигнализирует, когда используется не вся полоса пропускания.
В начале проигрывания перед непосредственным воспроизведением можно выполнить тестирование полосы пропускания и выбрать начальную дорожку, максимально подходящую под текущие сетевые условия.

Как тестировали

Инструменты

Для тестирования использовался мультибитрейтный видеофайл:

shaienn@oem:~/proj/flussonic/priv$ -ffprobe ./camera_mbr.mp4 
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from './camera_mbr.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp42
    creation_time   : 2022-07-22T05:33:30.000000Z
  Duration: 00:04:59.96, start: 0.000000, bitrate: 4992 kb/s
    Stream #0:0(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 96 kb/s (default)
    Metadata:
      creation_time   : 2022-07-22T05:33:30.000000Z
      handler_name    : SoundHandler
    Stream #0:1(eng): Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, fltp (default)
    Metadata:
      creation_time   : 2022-07-22T05:33:30.000000Z
      handler_name    : SoundHandler
    Stream #0:2(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 2996 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc (default)
    Metadata:
      creation_time   : 2022-07-22T05:33:30.000000Z
      handler_name    : VideoHandler
    Stream #0:3(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1024x576 [SAR 1:1 DAR 16:9], 1196 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc (default)
    Metadata:
      creation_time   : 2022-07-22T05:33:30.000000Z
      handler_name    : VideoHandler
    Stream #0:4(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 640x480 [SAR 1:1 DAR 4:3], 499 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc (default)
    Metadata:
      creation_time   : 2022-07-22T05:33:30.000000Z
      handler_name    : VideoHandler
    Stream #0:5(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 320x240 [SAR 1:1 DAR 4:3], 198 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc (default)
    Metadata:
      creation_time   : 2022-07-22T05:33:30.000000Z
      handler_name    : VideoHandler

И различные виды шейперов, например, tc шейпер для Linux.

Тесткейсы

При тестировании использовались метрики браузера chrome://webrtc-internals и логирование событий внутри Flussonic. Все тесты производились в локальной сети на версии Flussonic 22.07.1.

Тест1. Старт с самой низкобитрейтной дорожки. Замер времени до достижения самой высокобитрейтной дорожки.

Левая шкала по оси Y показывает битрейт в Mbps. По оси X указано 22-е число и HH:MM

Видно, что в случае с REMB механизм оценки битрейта не смог за 5 минут поднять значение битрейта для переключения на самую лучшую дорожку. Бывают случаи, когда механизму удаётся поднять битрейт до нужной величины.

Видно периодическое резкое снижение и затем восстановление оценки битрейта в случае с REMB. Также видна некая волнообразность и в случае с TWCC, возможно, внутренний GCC алгоритм браузера обрабатывает какие-то ситуации при проигрывании более строго.

Использование механизма REMB

Здесь:

серый цвет — характеристика bytesReceived_in_bits/s
оранжевый цвет — моменты переключения битрейта проигрываемой дорожки
красный цвет — характеристика availableIncomingBitrate

Использование механизма TWCC

Здесь:

серый цвет — характеристика bytesReceived_in_bits/s
оранжевый цвет — моменты переключения битрейта проигрываемой дорожки
красный цвет — текущая оценка величины полосы пропускания внутренним алгоритмом Flussonic

Тест2. Старт с самой высокобитрейтной дорожки. Ограничение траффика на уровне самой низкобитрейтной дорожки на несколько секунд. Замер времени восстановления битрейта до уровня самой высокобитрейтной дорожки.

Как делать нельзя

В процессе прототипирования была попытка анализировать задержку всех исходящих пакетов и производить оценку загруженности сети по такому же принципу, как это реализовано в GCC, а имитацию повышения битрейта делать путём добавления padding части к payload пакетам. От этого решения отказались, поскольку в такой реализации, при отстутствии каких-то значимых плюсов, генерирутся много бессмысленного траффика, который просто тратит сетевые ресурсы, имитируя повышающийся битрейт.

Как попробовать

Пока TWCC механизм в процессе тестирования и обкатки, Flussonic по умолчанию продолжает использовать REMB механизм.

Если вы хотит попробовать механизм TWCC, укажите в конфурации потока специальные параметры bitrate_prober и bitrate_probing_interval (более подробное описание смотрите в документации Flussonic).

Если вам необходима помощь или у вас есть вопросы, пишите нам по адресу support@flussonic.com.