Возможности и ограничения WebRTC для многоточечной ВКС

.

Основной способ использования «многоточки» – это проведение дистанционных встреч с неограниченным количеством участников, где каждый из собеседников и видит, и слышит всех остальных. Конфигурации клиентских устройств и сетей, в данном случае, достаточно разнообразны, а, следовательно, спектр проблем с которыми сталкиваются разработчики, также достаточно широк. При организации конференции необходимо учитывать конфигурации и качество сетей (NAT/Firewall), а также мощности клиентских устройств. Каждый из этих факторов оказывает влияние на качество видео-конференц-связи, построенной на WebRTС, и требует целенаправленных усилий разработчиков для определения оптимальной схемы организации конференции. 

Преимуществ у WebRTC как медийного протокола достаточно много: он фактически вобрал в себя все самые лучшие наработки в области передачи и защиты данных (использование ICE протокола для прохода сложных конфигураций сетей, использование ULFPEC/NACK для защиты передачи данных по сети и т.д.), но и недостатки у него тоже есть. Самым серьезным из них являются функциональные ограничения видеокодека VP8: он настолько проще технологически, что его даже сложно сравнить с видеокодеком H.264, используемым в плагине Adobe Flash.

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

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

Конференция №1. Одна общая мозаика

Это самый простой, недорогой и распространенный способ реализации конференции. Все видеопотоки декодируются и объединяются в одну большую мозаику. Видеопоток от мозаики в случае одинаковых клиентов (в данном случае WebRTC) кодируется только одним видеокодером. В данную схему также легко интегрируются видеотелефоны сторонних производителей с использованием SIP-сигнализации (Polycom, Cisco/Tandberg и др.) и добавляется всего один процесс кодирования - для H.264.

Плюсы:

• Нет необходимости покупать мощные сервера для MCU. Число серверов и мощность процессора очень легко рассчитать, исходя из условия, что одна конференция – это один/два видео-кодера;
• Простая схема реализации.

Минусы:

• Отсутствие адаптивности: все клиенты всегда будут получать одинаковый трафик, вне зависимости от своей пропускной способности;
• Каждый пользователь видит себя в мозаике с определенной задержкой - это достаточно неудобно и вызывает определенный дискомфорт у пользователей.

Единственный способ усилить эту схему, избавившись от отсутствия адаптации, - это расширить возможность RTP-шлюза, реализующего WebRTC, то есть просто задействовать заложенный механизм определения доступной ширины канала для клиентского приложения, а для видеокодера включить функциональность Temporal SVC и, добавив еще пару видеокодеров, генерировать несколько разрешений такой мозаики. Другими словами, реализовать полноценный VP8 SVC функционал за счет увеличения числа видеокодеров.

Конференция №2 - Расширенная мозаика

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

Плюсы:

• каждый участник конференции имеет свою индивидуальную мозаику.

Минусы

• дороговизна и избыточность схемы конференции.

Предположим, что каждому пользователю раздается мозаика в разрешении 720p. При использовании
Intel Xeon 2.4GHz (24 ядра) можно будет одновременно запустить порядка 80 кодеров VP8 (VP8 кодирует
720p со средней загрузкой около 30% ядра). Если, скажем, в конференции принимает участие четыре человека, то на таком, достаточно дорогом, сервере одновременно можно запустить всего лишь 20 конференций, что сильно повышает их стоимость.

Конференция №3 - Кодированные стримы и псевдо-SVC

Такой вид конференции уже не раз рассматривался и, в принципе, данная методика является основной при реализации конференции без транскодинга. Каждый пользователь отдает один видеопоток и получает в ответ N-1 кодированных потоков, где N - число участников конференции. Безусловно, данная схема подкупает своей простотой и дешевизной, но из-за отсутствия в схеме видеокодеров «проседает» автоадаптация от MCU до клиента.
Благодаря возможностям стандарта WebRTC эту проблему можно решить небольшим расширением, показанным на рисунке ниже.

Как видно из схемы, каждый пользователь теперь публикует два видеопотока: один большой (порядка
640х480@25fps) и второй маленький (128Х64@5fps), при этом продолжая получать N-1 потоков от MCU. Основной особенностью данной схемы является использование функционала WebRTC для определения пропускной способности удаленной стороны: MCU определяет, когда у клиента возникают проблемы с получением видео в связи с уменьшением пропускной способности, и тогда он перестает публиковать ему видеопоток большого разрешения и подменяет его на малый. Пользователь замечает проблемы в своей сети только за счет определенного ухудшения качества получаемой картинки, но тем не менее не перестает видеть собеседников и остается в курсе происходящего. Как видно из схемы, такой тип схемы почти лишен недостатков и реализует так называемую псевдо-SVC, а также показывает, чего же действительно не хватает WebRTC, - полноценного SVC.

Заключение

Мы рассмотрели далеко не все способы реализации многоточечной конференции с использованием текущего варианта стандарта WebRTC и возможностью подключения и/или интеграции существующих медиаклиентов. Комбинируя его с различными вариантами сигнального протокола, транспорта и кодеков, можно создавать схемы, которые могут легко сочетаться с уже установленными у заказчиков ВКС-решениями, благодаря чему интеграция новых технологий будет проходить достаточно быстро и недорого.

Самым главным и значительным усилением WebRTC будет кодек VP9, над которым сейчас работает Google в сотрудничестве с Vidyo: он позволит избавить стандарт от излишнего кода, упростит конфигурации конференций, максимально оптимизирует используемый трафик и процессорные мощности. Вследствие этого все приведенные в статье схемы конференций могут быть пересмотрены в сторону уменьшения их стоимости.

Для справки: VP9 уже поддержан в браузерах Chrome и Firefox и, по неофициальным сведениям, будет доступен в рамках протокола WebRTC уже в этом году.

Термины:

• MCU (Multi Conference Unit) - программно-аппаратный комплекс, реализующий медиа сервер для проведения многоточечной конференции.
• Видеокодер  – процесс (алгоритм) сжатия видеопотока.
• Видеодекодер  – процесс (алгоритм) расшифровки видео-потока
• SVC (Scalable Video Coding) - расширение алгоритма работы видеокодера, позволяющего сохранять несколько слоев в одной итерации кодирования потока.
• Temporal SVC - кодирование нескольких частот (FPS) за один проход.
• Spatial SVC - кодирование нескольких разрешений за один проход.