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

30 Апреля 2014

Усилия компании Google, направленные на усовершенствование и повсеместное внедрение стандарта WebRTC (англ. Real-Time Communications – коммуникации в реальном времени) – интернет-протокола с открытым исходным кодом, предназначенным для передачи потоковых данных между браузерами, дают о себе знать: буквально все крупные игроки на рынке решений для видеосвязи уже обратили внимание на этот технологический прорыв. Появление открытой платформы для передачи аудио и видео вызвало бурную волну обсуждения среди экспертов о перспективах стандарта и его готовности стать заменой существующим и давно зарекомендовавшим себя технологиям (в первую очередь, речь идет безусловно об Adobe Flash).

В силу того, что 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: он позволит избавить стандарт от излишнего кода, упростит конфигурации конференций, максимально оптимизирует используемый трафик и процессорные мощности. Вследствие этого все приведенные в статье схемы конференций могут быть пересмотрены в сторону уменьшения их стоимости.

Ознакомиться с полным текстом статьи можно на сайте: http://www.osp.ru/.

Автор – Герман Коровкин, руководитель группы медийной разработки компании Mind

Создание сайта — ADV
Яндекс.Метрика Google+