Многопользовательский WebRT C без SFU

Question

На основании этой статьи , при реализации решения WebRT C без сервера, я предполагаю, что это означает SFU, узкое место в том, что могут работать только 4-6 участников.

Есть ли решение, которое может обойти это? Например, я просто хочу использовать Firebase как единственный бэкэнд, в основном сигнализацию и без SFU. Какова общая стратегия внедрения для достижения как минимум 25-50 участников WebRT C?

Обновление: Этот проект Github использует другое утверждение. В нем говорится: «Полный я sh отлично подходит для ~ 100 подключений»

Answer 1

Если вы хотите провести конференцию с 25 людьми, отправляющими свое видео, обычная настройка webrt c не будет работать. За исключением случаев, когда вы значительно снижаете качество видео. Причина этого в том, что каждому участнику потребуется отправить 24 отдельных потока каждому другому клиенту. Допустим, у вас поток 128 КБ / с, тогда вам понадобится скорость загрузки 3 МБ / с. Что не всегда доступно. Затем также загрузите ту же сумму.

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

Например, вы можете использовать шлюз Janus или mediasoup. Вот уже настроенное приложение для видеоконференций mediasoup, которое масштабируется репозиторий github

Answer 2

Ваше реальное узкое место с ME SH заключается в том, что каждое соединение RTCPeerConnection будет выполнять собственное кодирование видео в браузере.

Концепция p2p, естественно, включает требование, чтобы оба узла настраивали качество кодирования в зависимости от условий сети. Итак, когда ваш браузер отправляет два потока одноранговым узлам X (хорошая скорость загрузки) и Y (плохая скорость загрузки), кодировки для X и Y будут разными - Y получит меньшую частоту кадров и битрейт, чем X.

Звучит разумно, правда? Но, к сожалению, требует отдельного кодирования видео для каждого однорангового соединения.

Если бы несколько одноранговых соединений могли повторно использовать одно и то же кодирование видео, то ME SH был бы намного более жизнеспособным. Но Google не предоставил такую ​​возможность в браузере. Для Simulcast требуется SFU, так что это не ваш случай. 5-6, не более. Для 640х480 15 кадров в секунду? Может быть, 20 кодировок.

На мой взгляд, уровень кодирования и сетевой уровень можно разделить в дизайне WebRT C, и даже getUserMedia можно расширить до getEncodedUserMedia, чтобы вы могли отправлять один и тот же закодированный контент нескольким peers.

Вот и настоящая практическая причина, по которой люди используют SFU для многопользовательского WebRT C.