Высокое качество связи при стабильном соединении

6 Август, 2019
6 мин

Как добиться масштабируемости конференции в реальном времени с минимальными задержками?

Введение

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

С развитием WEB-технологий, идея о том, что все программное обеспечение должно быть доступно прямо из браузера, набирает популярность. Для пользователей нет нужды устанавливать приложения, а для разработчиков больше нет необходимости думать о совместимости и кроссплатформенности. WEB-технологии успешно применяются в IoT, позволяя запускать самые различные устройства включая телевизор, автомобиль или даже микроволновку. Создание эффективного канала коммуникации для WEB — задача актуальная, хоть и непростая. Ее решением занимаются все ведущие разработчики браузеров последние десять лет.
В наше время термины «онлайн-конференция», «видеозвонок», «совместная демонстрация» становятся все более узнаваемыми и распространенным. Во многом благодаря высокотехнологичным достижениям, перед ними появляется такая желанная приставка «web-«.

One-To-Many — просто

Передача аудио/видео через Всемирную сеть уже давно не является комплексной задачей. Для передачи медиа через интернет, необходимо:

  • получить сигнал от устройства захвата (камера /микрофон)
  • преобразовать формат сигнала в компактный вид (кодировать/сжать)
  • передать полученные данные по сети
  • распаковать полученные данные (декодировать).

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

Самый распространенный кодек для передачи видео —  проприетарный `H264`

H264 имеет очень высокие показатели сжатия при относительно маленьких потерях качества. При этом, большинство производителей техники встраивают аппаратный кодировщик H264 в свои устройства. Сжатие в H264 очень сложное, занимает большее количество ресурсов, в то время как распаковка является более простым процессом. H264 — порядком устаревшая технология, которая напрямую использовалась для Flash. Учитывая, что Flash не предназначен для real-time коммуникаций, использование технологий на его основе крайне сложно воплотить в WEB. H264 являлся неотъемлемой частью устаревшей технологии Flash, что способствовало его активному внедрению в WEB технологии.  
Альтернативой с открытым исходным кодом является кодек VP8/VP9. В отличие от h264, последний имеет ориентированность на отправку в реальном времени, а поэтому имеет более простой процесс упаковки.

Схема передачи одного медиа-сигнала ко многим получателям сравнительно проста и имеет отличную масштабируемость. Получая единственный поток на сервере, необходимо всего лишь предоставить к нему доступ, используя для этого любой популярный транспорт (например HTTP).  Расширить доступность подобного сигнала можно с помощью CDN, VDN или любого подобного сервиса. Синхронизация времени здесь отсутствует. При этом задержки во времени не только допустимы, но и не  влияют на восприятие контента. Такой метод хорошо подходит для проведения вебинаров и стримингов. 

Many-To-Many hell


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

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

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

Масштабируемость multiparty-связи является достаточно проблематичным процессом. Распределить сигналы на стороне сервера, сохранить временную синхронность, и не создать при этом задержек требует алхимических усилий. 

Лимитирование 

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

Как с этим жить ?

Для преодоления подобных проблем необходимы особые решения на всех этапах передачи видеосигнала:

  1. Видео кодек должен быть оптимизирован для быстрого сжатия сигнала. Распаковка же должна позволять обработку поврежденного сигнала, или сигнала с потерянными пакетами.
  2. На уровне транспорта рекомендуется отказаться от строгого контроля доставки пакетов. При этом пакеты должны быть доставлены как можно быстрее, не дожидаясь доставки предыдущих, дожидаясь только отправки. Для этого очень хорошо подходит протокол UDP. Чтобы максимально сократить задержки на уровне транспорта, можно использовать P2P подключение (прямое соединение между двумя участниками), минуя сервер.

Все эти проблемы качественно решает WebRTC. WebRTC — это набор решений и технологий. Он включает в себя технологии,          API и протоколы для оптимальной транспортировки, кодирования, коррекции ошибок, контроля задержки и пропускной                    способности. Ко всему, WebRTC также содержит решения для сетевого обнаружения и обхода NAT и фаерволов.

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

Такая топология называется “full-star” и имеет очень жесткие рамки. Количество участников такого звонка строго лимитировано шириной канала для каждого из пользователей. Это решение позволяет использовать прямое подключение между пользователями и убирает задержки серверной обработки. Этот подход хорошо подходит для конференций до 5 человек.

Чтобы избежать необходимости отправлять один и тот же сигнал каждому из участников, хорошо бы отправлять этот сигнал в одно место, а оттуда уже распределить между пользователями. Каждый пользователь будет отправлять сигнал единожды, а получать его от каждого из пользователей. Таким образом, количество одновременных участников в конференции возрастает в несколько раз.
Такой подход называют SFU (Selective forwarding unit). 

Если распаковать видеосигнал на стороне сервера, склеить его с другими и отправить получателям, то пользователь мог бы отправлять свой сигнал серверу один раз и получать от него один сигнал, включающий в себя все сигналы остальных пользователей. Такой подход позволяет увеличить количество пользователей, которые могут быть отображены компьютером клиента в пределах ограничений производительности и сети. Проблема в том, что этот же подход имеет большие недостатки. Один из таких недостатков — необходимость обработки (распаковки/запаковки) медиа на стороне сервера. Это создает задержку, разрушает синхронизацию и требует весомых ресурсов на содержание такой инфраструктуры.
Такой подход называется MCU.

Говоря о масштабировании, лучшей является топология MCU (пользователь получает один поток и отправляет один, при любых обстоятельствах), а оптимальной — SFU (не требует сложной обработки на сервере).

Чтобы убрать ограничение количества участников для SFU, можно ограничить количество видеосигналов, доставляемых каждому участнику. Предположим, что пропускная полоса пользователя позволяет отправлять собственный сигнал и получать 5 видеосигналов других участников. С точки зрения пространства на экране и сохранения актуальности беседы, большее количество видеосигналов достаточно проблематично отобразить, и такой формат достаточно трудно было бы воспринимать. 

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

Таким образом, лимитирование количества участников со стороны клиента пропадает. 

Оптимизация

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

send-side, recv-side и другие дают возможность установить оптимальное количество доставляемых видео для каждого пользователя и делать это динамично в реальном времени.
Исходя из того, что, как правило, активно говорящий пользователь только один, логичным будет доставить его видео в более высоком качестве, чем остальных пользователей.

Simulcast 

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

Заключение

Как же все-таки добиться масштабируемости конференции в реальном времени при минимальных задержках?

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

Если 

  • правильно распорядиться всеми доступными средствами контроля связи
  • найти компромисс между стоимостью инфраструктуры и масштабируемостью
  • использовать пропускную способность интернет-канала пользователя с максимальной пользой, 

тогда

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

Tatiana Romanova