Черт возьми, webRTC сбивает с толку. Я чувствую, что существует бесконечное множество странных терминов и аббревиатур. Создавая свое приложение для потокового вещания Ohmystream, я исследовал способы, позволяющие нескольким участникам общаться во время потокового вещания. Сейчас приложение поддерживает только одиночных стримеров. Раньше я создавал Ohmystream, используя React, Node JS, веб-сокеты и FFmpeg, не задумываясь о включении нескольких участников. Добавление webRTC — это значительный дополнительный уровень сложности, поскольку в зависимости от того, в каком направлении вы идете, существуют четкие ограничения. Например, вам нужно поддерживать только 4 участников или ближе к 30 участникам? Есть ли у ваших пользователей устройства, способные выполнять сложные вычислительные задачи на клиенте? У вас есть сервер, способный справиться с потенциально очень большой вычислительной нагрузкой? Ниже я расскажу об архитектурах MESH, MCU и SFUWebRTC и их компромиссах.
MESH: это самый простой способ настройки, в котором используется одноранговая сеть. По сути, каждый участник отправляет свой поток напрямую каждому другому участнику, минуя медиа-сервер. Участник также получает потоки от всех остальных пользователей. Итак, если участников 4. Вы отправите свой поток другим трем пользователям, а также получите все их потоки. Как вы можете себе представить, этот подход плохо масштабируется после более чем 6 пользователей, потому что он требует, чтобы ваш компьютер получал и обрабатывал кучу аудио- и видеопотоков. Mesh поддерживает до 4–6 участников и не требует центрального медиа-сервера, что упрощает настройку, но не масштабируется.
Блок управления многоточечной связью (MCU):
MCU поддерживает большее количество участников, чем MESH. Каждый участник отправляет свой поток на сервер, а сервер декодирует поток каждого участника и создает один новый поток из каждого из полученных потоков. Наконец, он отправляет этот поток обратно всем участникам.
По сравнению с архитектурой MESH MCU переносит большую часть обработки с клиента на сервер. Недостатком подхода MCU являются высокие затраты на сервер, поскольку декодирование каждого потока и повторное кодирование потока для отправки обратно каждому клиенту может потребовать значительных вычислительных ресурсов. Кроме того, поскольку задействован сервер, может быть больше задержки при отправке перекомпонованного потока обратно каждому клиенту. Я настоятельно рекомендую ознакомиться с презентацией Toyko Meetup, так как она содержит отличную информацию о том, что возможно с MCU.
Выборочные единицы пересылки (SFU):
Это более популярный подход, чем MCU, когда необходимо масштабирование до более чем 4–6 участников. Этот подход также включает сервер. Разница в том, что каждый участник отправляет свой поток на сервер, а сервер отправляет каждый полученный поток обратно всем остальным участникам. Например, если участников 6, каждый участник получит по 5 потоков от других пользователей. Самое замечательное в SFU заключается в том, что его можно масштабировать, и у вас больше гибкости в пользовательском интерфейсе. На клиенте вы можете изменить порядок участников, тогда как в MCU это невозможно. Это может позволить вам иметь собственные макеты и изменять их во время работы. Видимо Jitsi использует SFU. Также вот действительно классный проект с открытым исходным кодом под названием MediaSoup, который использует SFU с несколькими примерами.
Источники:
