Вебинар на WebRTC без медиасерверов
Возможно ли реализовать видео трансляцию тысяче пользователей без медиа серверов? WebRTC казалось бы подходит для этого — peer to peer технология, клиенты передают данные друг другу без посредников. Но если мы подключим всех желающих посмотреть прямой эфир напрямую к источнику, то клиент просто не выдержит такой нагрузки и трафика.
Нам придется ограничить число исходящих видеопотоков. А чтобы видео дошло до всех клиентов, мы попробуем соединить их между собой по цепочке. Мы оценим возможность применения соединения по цепочке в реальных проектах, ориентируясь на качество картинки, задержки сигнала и его восстановления в случае разрыва одного из узлов цепочки.
Как реализовывать вебинар на WebRTC?
Чаще всего видеопоток в вебинарах передают от ведущего через сервер к зрителям. Или напрямую от ведущего к ограниченному числу зрителей. Мы же предлагаем схему: Ведущий — Зрители — Зрители Ведущий — Сервер — Зрители
Pисунок 1: Организация вебинара с использованием медиа сервераx
Перед нами самая популярная реализация. Нагрузка на ведущего и зрителей в такой схеме минимальна. Все проходит через сервер.
Плюсы:
- Потенциально, стабильное качество видео — только один посредник между ведущим и зрителями.
Минусы:
- Большая нагрузка на медиа сервер.
Ведущий — Зрители
Pисунок 2: Организация вебинара с подключением зрителей напрямую к ведущему
В этой реализации мы экономим на сервере — вся нагрузка ложится на ведущего вебинара. Он отдает видеопоток каждому клиенту отдельно и требования к пропускной способности канала прямо пропорциональны количеству клиентов. Схема подходит для ограниченного числа зрителей. Уже после пятого соединения у многих пользователей начнутся проблемы.
Плюсы:
- Не нужен медиа сервер.
- Простота реализации.
- Минимальное время задержки — только время передачи данных от организатора к зрителям.
Минусы:
- Максимальное количество зрителей ограничено пропускной способностью канала ведущего.
Ведущий — Зрители — Зрители (Цепочка)
Pисунок 3: Организация вебинара с использованием промежуточный узлов-зрителей
В реализации цепочкой Ведущий вебинара транслирует свои данные первым N1 зрителям, эти зрители ретранслируют поток Ведущего следующим N2 зрителям и так далее. Мы получаем: минимальную нагрузку на сервер, как в схеме Ведущий — Зрители, и возможность иметь большое число клиентов, как в схеме Ведущий — Сервер — Зрители.
Плюсы:
- Не нужен медиа сервер.
- Нагрузка на трансляцию равномерно распределяется по участникам.
Минусы:
- C ростом цепочки клиентов увеличивается задержка и ухудшается качество.
- Сложность реализации приемлемой защиты от отключения узлов.
Как реализовать цепочку?
Для реализации цепочки необходимо обработать две ситуации: подключение и отключение пользователя. При наличии у ведущего свободных слотов новый зритель создает соединение с ним, иначе со свободным родителем. Сам пользователь при этом добавляется в список свободных родителей. Очевидной проблемой становится отключение одного из родителей.
Существует несколько способов решения.
Способ № 1:
Pисунок 4: Восстановление подключения
Первый способ самый простой. При подключении нового зрителя ему назначается свободный родитель, запасные каналы в данной реализации отсутствуют. После того как родитель покинул комнату, его зрителям по цепочке необходимо найти нового родителя. В данном случае у зрителей на промежуток времени от разрыва со старым родителем до установления соединения с новым пропадает картинка с видеопотоком (1-5 секунд в зависимости от параметров подключения участников).
Плюсы:
- Простота реализации.
Минусы:
- При отключении родителя пропадает картинка у всех его зрителей на несколько секунд.
- Возможна потеря части видеотрансляции из-за разницы в задержках.
- Для каждого зрителя в цепочке после отключившегося родителя необходимо искать нового родителя.
Способ № 2:
Pисунок 5: Восстановление подключения c использованием запасного соединения с медиа сервером
При подключении нового пользователя устанавливаем дублирующее соединение с сервером. Когда родитель покидает комнату, все его зрители переключаются на запасной медиа канал с сервером, пока ищется новый родитель.
Плюсы:
- При отключении родителя картинка пропадает на небольшой промежуток времени.
Минусы:
- При отключении родителя значительно возрастает нагрузка на сервер.
- Возможна потеря части трансляции из-за разницы в задержках.
- Необходим медиа сервер для дублирующих соединений.
Способ № 3:
Pисунок 6: Восстановление подключения c использованием запасного соединения с медиа сервером только для прямых потомков
Теперь когда родитель покидает комнату, только его прямые зрители начинают искать новый источник и включают передачу данных с дублирующего соединения.
Плюсы:
- Необходимо искать нового родителя только следующем в цепочке зрителем.
- Меньшая нагрузка на сервер по сравнению с предыдущим вариантом.
Минусы:
- Возможна потеря части трансляции из-за разницы в задержках.
- Реализация сложнее чем у предыдущего варианта.
Способ № 4:
Pисунок 7: Восстановление подключения c использованием запасного соединения c соседом родителя
При подключении пользователь устанавливает соединение с двумя родителями. В этом случае, когда родитель покидает комнату, прямые потомки начинают искать нового родителя и включают дублирующее соединение (пока устанавливается новое).
Плюсы:
- При отключении родителя картинка у зрителей пропадает на минимальное время.
- Минимальная нагрузка на сервер.
Минусы:
- Увеличивается нагрузка на родителя в момент активации подключенных к нему дублирующих соединений.
- Сложность реализации.
Мы остановились на первом способе, как наиболее простом в реализации.
Устройство Frontend
Пользователь при заходе видит страницу с полем для ввода названия комнаты и кнопками для создания и подключения к ней. Ведущий отправляет событие о создании комнаты на сервер, запрашивает доступ к микрофону и видеокамере и ждет запрос на создание PeerConnection. Первые участники подключаются к ведущему пока не закончится квота сервера на подключение к ведущему, последующие к другим участникам. Участник отправляет событие на сервер о подключении к комнате, получает и отправляет SDP и Ice Candidate. После чего получает и выводит видеопоток от родителя. Отличие в поведении участника от ведущего в том, что он не запрашивает доступ к видеокамере и микрофону и не получаем с них медиапоток. А также передает видеопоток родителя дальше. При отключении родителя участники получают сообщение о необходимости установить новое соединение.
Устройство Backend
Backend часть состоит из сокет сервера, который выполняет роль сигнального сервера. Когда пользователь создает комнату, он становится ведущим вебинара (далее ведущий) и первым свободным стримером-родителем (далее родителем). При подключении нового участника ему назначается первый доступный родитель, а сам участник добавляется в список доступных. При отключении участника его детям отправляется событие о том, что их родитель вышел.
Задержки и качество видеотрансляции
Для проверки качества и задержек видеотрансляции мы провели тестовый вебинар. Зрители были распределены по городу Санкт-Петербургу. Были использованы различные способы подключения к интернету: Wi-Fi, витая пара, LTE. Ведущий был подключен по LTE. Число в левом верхнем углу на результатах указывает на количество узлов между источником(включая сам источник) и зрителем, то есть 0 число — сам источник, 1 — зритель получает трансляцию напрямую от источника, 2 — зритель получает трансляцию от зрителей с числом 1 и т.д.. Результаты трансляции:
Pисунок 8: Видеопоток с одним промежуточным звеном
На уровне 2 качество трансляции на хорошем уровне, минимальные задержки, близко по результатом к классической схеме использованием медиа сервера, так как всего 1 посредник между источником и зрителем.
Pисунок 9: Видеопоток с четырмя промежуточными звеньями
На уровне 5 уже заметно падение качество видео, задержки варьируется от 1-2 секунд в большую часть времени.
Pисунок 10: Видеопоток с семью промежуточными звеньями
Потеря качества трансляции и задержки на уровне 8. При таком уровне потери качества проведения трансляции не представляется возможным.
Максимальное количество зрителей зависит от нескольких факторов: как расположены зрители географически, изначальное разрешение видеопотока, пропускная способность интернет-каналов участников трансляции. На основе полученных результатов для приемлемого качество мы можем взять 5 уровней посредников и 3 ретрансляции в каждом узле (такое число ретрансляций которое должны выдержать даже самые слабые современные компьютеры и минимальные интернет-каналы). С такими числами, максимальное число зрителей равно 273.
Заключение
По результатам тестов делаем вывод, что реализация соединения цепочкой возможна и будет работать для 10-300 зрителей, в зависимости от требований к качеству видео и изначальному разрешению. Также этот подход можно комбинировать с использованием медиа сервера, минимизируя на нем нагрузку. Например, мы транслируем видео через медиасервер 1000 зрителям. Добавив хотя бы один уровень цепочки, мы уменьшим трафик на сервер минимум в два раза. При этом потеря качества на одном уровне будет незначительной.