Как стать автором
Обновить

Как сделать многоточечную WebRTC-конференцию MCU с записью и демонстрацией экрана в браузере

Время на прочтение15 мин
Количество просмотров7K
Всего голосов 4: ↑4 и ↓0+4
Комментарии11

Комментарии 11

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

Не верно. VP9 поддерживает SVC из коробки. По крайней мере chrome. firefox, кажется - тоже. Правда нормальное API до сих пор не стандартизовано, поэтому SVC конфигурируется немножечко костыльно - задаете как бы simulcast, но ставите кодек vp9. Получаете на выходе один поток со spatial слоями вместо simulcast'а.

Еще, помимо spatial маcштабируемости - есть еще temporal масштабируемость: часть кадров можно просто выкинуть из потока и он остается декодируемым. Обычно используют 3 слоя.

Вот, правда, что из этого поддерживает WCS - я не в курсе. Думаю, есть SFU которые умеют в vp9.

Правда нормальное API до сих пор не стандартизовано

Именно поэтому нельзя считать, что технология поддерживается. Пока нет четкого стандарта, ничто не мешает Google с успехом сломать однажды все предыдущие решения. В последних сборках Canary, например, они опять сломали аппаратное кодирование H264, на этот раз при захвате с канваса. Починят, конечно, но вопросы у клиентов появляются.
Вот, правда, что из этого поддерживает WCS — я не в курсе. Думаю, есть SFU которые умеют в vp9.

WCS уже умеет в ядре simulcast получать и раздавать для VP8 (полноценно) и H264 (тут с некоторыми ограничениями). Сейчас работаем над API и заготовками интерфейса, поскольку большинство клиентов хотят свой Zoom с фишками, но без лишнего труда. Скорее всего, в этом году будем выводить в продакшн.

Откуда такая интересная классификация серверов? Почему simulcast и SVC переехали из технологий управления качеством входящего изображения в виды серверов конечной поставки данных?

Ничто не мешает использовать simulcast или SVC как на SFU так и на MCU.

Откуда такая интересная классификация серверов?

Уточните, пожалуйста, где именно Вы видите классификацию серверов? В статье приведен список технологий. И да, эти технологии могут быть использованы совместно, но это усложнит примеры реализации, а статья предназначена, как писали раньше, «для широкого круга читателей»

Вы говорите об архитектурах систем видеоконференций, но simulcast и SVC не являются архитнктурными решениями. Они вообще к архитектуре никак не относятся.

Почему же?
Например, использование этих технологий снижает требования к каналу зрителя, но повышает к каналу паблишера, он должен отдать все варианты качества. А выбор каналов — это уже архитектурная часть, т.к влияет на выбор хостера/датацентра/сервера.
А если мы будем выходной поток микшера отдавать в различных вариантах качества, это опять же влияет на выбор сервера, т.к. требует более мощного процессора или GPU, смотря на чем кодировать.

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

В нашей практике бывали случаи, когда клиенту приходилось разделить CDN на два сегмента по континентам, отдельно для публикаций из Америки и отдельно из Европы, иначе канала между датацентрами на континентах не хватало для толстых (4K) потоков в нужном количестве. А это уже архитектура решения.
Надеюсь, теперь достаточно ясно, почему мы отнесли и выбор технологии бродкастинга к архитектурным задачам?

Ну так это все равно о посылке исходящего трафика и данная пробема не определяет будет ли использован simulcast или SVC, или не будет. Она не определяет даже какой тип сервера может быть использован. Это просто проблема масштабируемости и доступности сервиса.

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

В freeswitch конференции так же работают. Можно запустить без js кода, используется web rtc sip клиент (sip.js или аналог). Там тоже у бекенда есть и запись конференций и можно получать видео как одним файлом, в котором картинки объединены, как у вас так и запрашивать от каждого пользователя отдельно видеопотоки.

Конечно это уже использование фреймворков, но зато быстрый старт и проверить нагрузку на пользовательские пк и сервер.

А сверху уже можно писать свой фронтенд, когда логика определится)

FreeSwitch дает более специализированное решение и предназначен для SIP, а WCS более универсален и работает с медиапотоками, которые могут быть, при необходимости, захвачены и из SIP звонков: 1, 2
Зарегистрируйтесь на Хабре, чтобы оставить комментарий