WebRTC - масштабируемая трансляция / мультикастинг в прямом эфире

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

Однако есть довольно простое решение, которое работает очень хорошо: я его протестировал, оно называется шлюзом WebRTC. Янус - хороший пример. Это полностью открытый исходный код (репозиторий github здесь).

Это работает следующим образом: ваш вещатель связывается со шлюзом (Janus) , который говорит о WebRTC. Итак, существует согласование ключей: B безопасно передает (зашифрованные потоки) Янусу.

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

Это хорошо работает, потому что вещатель (B) только один раз загружает свой поток на Janus. Теперь Янус декодирует данные, используя свой собственный ключ, и имеет доступ к необработанным данным (то есть, пакетам RTP) и может отправлять эти пакеты каждому посетителю (Янус позаботится о шифровании за вас). А поскольку вы помещаете Janus на сервер, у него отличная пропускная способность для загрузки, поэтому вы сможете передавать потоки многим одноранговым узлам.

Так что да, он действительно связан с сервером, но этот сервер использует WebRTC, и вы «владеете» им: вы реализуете часть Janus, поэтому вам не нужно беспокоиться о повреждении данных или о человеке посередине. . Ну, если, конечно, ваш сервер не скомпрометирован. Но вы можете сделать так много.

Чтобы показать вам, насколько легко использовать Janus, у вас есть функция с именем incoming_rtp() (и incoming_rtcp()), которую вы можете вызывать, которая дает вам указатель на пакеты rt (c) p. Затем вы можете отправить его каждому посетителю (они хранятся в sessions, который Янус очень упрощает в использовании). Здесь можно найти одну реализацию функции incoming_rtp(), парой строк ниже вы можете увидеть, как передавать пакеты всем участникам и здесь вы можете увидеть фактическую функцию ретрансляции пакета rtp.

Все работает неплохо, документацию довольно легко читать и понимать. Я предлагаю вам начать с примера "echotest", он самый простой и вы можете понять внутреннюю работу Януса. Я предлагаю вам отредактировать файл эхо-теста, чтобы создать свой собственный, потому что нужно написать много избыточного кода, поэтому вы также можете начать с полного файла.

Повеселись! Надеюсь, я помог.

Как отметил @MuazKhan выше:

https://github.com/muaz-khan/WebRTC-Scalable-Broadcast

работает в хроме, и пока нет аудиотрансляции, но, похоже, это первое решение.

Демонстрация масштабируемой одноранговой трансляции WebRTC.

Этот модуль просто инициализирует socket.io и настраивает его таким образом, чтобы одна трансляция могла быть ретранслирована неограниченному количеству пользователей без каких-либо проблем с полосой пропускания / использованием ЦП. Все происходит в одноранговой сети!

Это определенно должно быть возможно.
Другие тоже могут сделать это: http://www.streamroot.io/

AFAIK единственной актуальной и зрелой реализацией этого является Adobe Flash Player, который поддерживает многоадресную передачу p2p для одноранговой передачи видео с версии 10.1.

https://web.archive.org/web/20160306014615/http://tomkrcha.com/?p=1526.

«Масштабируемое» вещание невозможно в Интернете, потому что там не разрешена многоадресная рассылка IP UDP. Но теоретически это возможно в локальной сети.
Проблема с Websockets заключается в том, что у вас нет доступа к RAW UDP по дизайну, и он не будет разрешен.
Проблема с WebRTC заключается в том, что его каналы данных используют форму SRTP, где каждый сеанс имеет собственный ключ шифрования. Таким образом, если кто-то «не изобретает» или API не позволяет совместно использовать один сеансовый ключ между всеми клиентами, многоадресная рассылка бесполезна.

Есть решение доставки с привлечением партнеров, то есть подход является гибридным. И сервер, и одноранговые узлы помогают распределять ресурс. Это подход peer5.com и peercdn .com заняли.

Если мы говорим конкретно о прямой трансляции, это будет выглядеть примерно так:

1. Вещатель отправляет живое видео на сервер.
2. Сервер сохраняет видео (обычно также перекодирует его во все соответствующие форматы).
3. Создаются метаданные об этом прямом эфире, совместимые с HLS, HDS или MPEG_DASH.
4. Потребители переходят к соответствующему потоку в реальном времени, где игрок получает метаданные и знает, какие фрагменты видео получить дальше.
5. При этом потребитель подключается к другим потребителям (через WebRTC).
6. Затем игрок загружает соответствующий фрагмент либо непосредственно с сервера, либо с одноранговых узлов.

Следование такой модели может сэкономить до ~ 90% пропускной способности сервера в зависимости от битрейта прямого потока и совместной восходящей линии связи зрителей.

отказ от ответственности: автор работает в Peer5

Мои мастера сосредоточены на разработке гибридного протокола прямой трансляции cdn / p2p с использованием WebRTC. Я опубликовал свои первые результаты на http://bem.tv

Все с открытым исходным кодом, и я ищу участников! :-)

Ответ Ангела Генчева кажется правильным, однако существует теоретическая архитектура, позволяющая осуществлять трансляцию с малой задержкой через WebRTC. Представьте, что B (вещатель) передает поток A1 (участник 1). Затем подключается A2 (участник 2). Вместо потоковой передачи от B к A2, A1 начинает потоковую передачу видео от B к A2. Если A1 отключается, тогда A2 начинает получать от B.

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

На данный момент я использую решение на стороне сервера.

Я разрабатываю систему вещания WebRTC с использованием Kurento Media Server. Kurento поддерживает несколько видов потокового протокола, таких как RTSP, WebRTC, HLS. Он также работает в режиме реального времени и масштабирования.

Следовательно, Kurento не поддерживает RTMP, который сейчас используется в Youtube или Twitch. Одна из моих проблем - количество пользователей, одновременно работающих с этим.

Надеюсь, это поможет.

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

Уловка состоит в том, чтобы не обременять клиента потоковой передачи каждым зрителем и, как вы упомянули, иметь «ретрансляционный» медиа-сервер. Вы можете создать это самостоятельно, но, честно говоря, лучшим решением часто является использование чего-то вроде WebRTC от Wowza. Потоковый продукт.

Для эффективной потоковой передачи с телефона вы можете использовать Wowza GoCoder SDK, но, по моему опыту, лучше всего работает более продвинутый SDK, такой как StreamGears.

Поскольку peer1 - это только одноранговый узел, который вызывает getUserMedia (), т.е. peer1 создает комнату.

1. Итак, peer1 захватывает медиа и запускает комнату.
2. peer2 присоединяется к комнате и получает поток (данные) от peer1, а также открывает параллельное соединение с именем "peer2-connection"
3. Когда peer3 присоединяется к комнате и получает поток (данные) от peer2, а также открывает параллельное соединение с именем «peer3-connection» и так далее.

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

Следовательно, благодаря этому одна трансляция может быть передана неограниченному количеству пользователей без каких-либо проблем с полосой пропускания / загрузкой ЦП.

Наконец, все приведенное выше является ссылкой из Ссылка.

Я работаю над Relay версией WebRTC, но не уверен, что она будет работать. Мой тест предназначен только для одного пользователя Johnny и смотрю, может ли этот поток relayed быть другим пользователям.

1. У нас открыто два окна браузера. Первый - это пользователь Johnny, второй - специальный пользователь Relay.
2. На дисплее у вас будет local и remote видеоэлементы для тестирования.
3. При запуске просмотра пользователи, подключенные к Hub, автоматически отображаются в окне браузера.
4. Щелкните в первом окне пользователя Relay, и этот пользователь отобразится в элементе remote video первого окна браузера, а Johnny отобразится в окне remote второго окна браузера.
5. Теперь приходит большая уловка, все остальные пользователи, которые хотят подключиться к Johnny, должны будут подключиться к remote окну специального пользователя relay. В этом примере один пользователь, но relay окно может иметь больше окон (RTCPeerConnections) для подключения большего количества пользователей.
6. Окно браузера relay будет сервером для других пользователей. Все пользователи подключаются к relay окну браузера. RTCPeerConnections будет создан для каждого подключенного пользователя.

В моем примере я визуализирую это с помощью <video> элементов, но в relay окне браузера RTCPeerConnections должно быть достаточно.

Это логика идеи или я что-то упускаю?