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

ПРОБЛЕМА:

WebRTC дает нам одноранговые видео / аудио соединения. Идеален для p2p звонков, тусовок. А как насчет широковещания («один ко многим», например, от 1 до 10000)?

Допустим, у нас есть вещатель «B» и двое посетителей «A1», «A2». Конечно, это кажется разрешимым: мы просто соединяем B с A1, а затем B с A2. Таким образом, B отправляет видео / аудиопоток напрямую в A1, а другой поток - в A2. B отправляет потоки дважды.

А теперь представьте, что вас 10000 человек: A1, A2, ..., A10000. Это означает, что B должен отправить 10000 потоков. Каждый поток составляет ~ 40 КБ / с, что означает, что B требуется исходящая скорость Интернета 400 МБ / с для поддержания этой трансляции. Неприемлемый.

ОРИГИНАЛЬНЫЙ ВОПРОС (УСТАРЕЛ)

Можно ли как-то решить эту проблему, чтобы B отправлял только один поток на какой-то сервер, а посетители просто извлекали этот поток с этого сервера? Да, это означает, что исходящая скорость на этом сервере должна быть высокой, но я могу ее поддерживать.

А может, это означает разрушение идеи WebRTC?

НОТЫ

Flash не подходит для моих нужд из-за плохого UX для конечных клиентов.

РЕШЕНИЕ (НЕ ДЕЙСТВИТЕЛЬНО)

26.05.2015 - На данный момент нет такого решения для масштабируемого вещания для WebRTC, где бы вы вообще не использовали медиа-серверы. На рынке представлены как серверные решения, так и гибридные (p2p + серверная часть в зависимости от различных условий).

Хотя есть несколько многообещающих технологий, таких как https://github.com/muaz-khan/WebRTC-Scalable-Broadcast, но они должны ответить на эти возможные проблемы: задержка, общая стабильность сетевого соединения, формула масштабируемости (они, вероятно, не являются бесконечно масштабируемыми. ).

SUGGESTIONS

1. Уменьшите ЦП / пропускную способность за счет настройки аудио и видео кодеков;
2. Получите медиа-сервер.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Они обеспечивают масштабируемую потоковую передачу Webrtc с малой задержкой. Вот несколько примеров. Янус , Jitsi , Wowza , Red5pro , Ant Media Server

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

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

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

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

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

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

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

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

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

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

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

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