WebRTC - масштабируемое вещание в реальном времени/многоадресная передача

Ответ 1

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

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

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

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

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

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

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

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

Удачи! Надеюсь, я помог.

Ответ 2

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

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

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

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

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

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

Ответ 3

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

http://tomkrcha.com/?p=1526.

Ответ 4

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

Ответ 5

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

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

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

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

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

Ответ 6

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

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

Ответ 7

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

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

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

Ответ 8

На рынке доступно несколько решений для масштабируемого решения WebRTC. Они обеспечивают масштабируемую потоковую передачу webrtc с низкой задержкой. Вот несколько примеров. Янус, Джитси, Wowza, Red5pro, Ant Media Server

Я являюсь разработчиком Ant Media Server, мы предоставляем как корпоративную, так и корпоративную версию, включая Android и iOS SDK. Дайте нам знать, если мы можем помочь вам как-то.

Ответ 9

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

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

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

Ответ 10

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

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

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

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

Наконец, все вышеизложенное является ссылкой от Link.

Ответ 11

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

Хитрость заключается в том, чтобы не облагать налогом потоковый клиент для каждого зрителя и, как вы упомянули, иметь "ретранслятор" медиа-сервера. Вы можете создать это самостоятельно, но, честно говоря, лучшее решение - это часто использовать что-то вроде продукта Wowza WebRTC Streaming.

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