WebRTC - масштабована трансляція / трансляція трансляції в прямому ефірі

ПРОБЛЕМА:

WebRTC надає нам однорангові відео- / аудіозв’язки. Він ідеально підходить для дзвінків p2p, тусовок. А як щодо мовлення (один на багато, наприклад, 1 до 10000)?

Скажімо, у нас телекомпанія "В" та двоє відвідувачів "А1", "А2". Звичайно, це здається вирішуваним: ми просто з'єднуємо 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, але їм потрібно відповісти на такі можливі питання: затримка, загальна стабільність мережевого зв’язку, формула масштабованості (вони, можливо, нескінченно масштабовані ).

ПРОПОЗИЦІЇ

1. Зменшити процесор / пропускну здатність, налаштовуючи як аудіо, так і відео кодеки;
2. Отримайте медіа-сервер.

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

Однак є досить просте рішення, яке працює дуже добре: я протестував його, він називається шлюзом WebRTC. Янус - хороший приклад. Це повністю відкритий код ( тут знаходиться github repo ).

Це працює так: ваш мовник зв’язується із шлюзом (Janus), який говорить WebRTC . Отже, є ключові переговори: B надійно передає (зашифровані потоки) Янусу.

Тепер, коли учасники підключаються, вони знову підключаються до Janus: узгодження WebRTC, захищені ключі тощо. Відтепер Janus передаватиме потоки назад кожному учаснику.

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

Так, так, він дійсно залучає сервер, але цей сервер говорить WebRTC, і ви його "володієте": ви реалізуєте частину Janus, щоб вам не довелося турбуватися про корупцію даних або людину посередині. Ну, якщо, звичайно, не порушено ваш сервер. Але можна так багато зробити.

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

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

Веселіться! Сподіваюся, я допоміг.

Як @MuazKhan зазначав вище:

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

працює в хромі, і ще немає аудіопередачі, але, здається, це перше рішення.

Демонстрація демонстрації однорангових трансляцій WebRTC.

Цей модуль просто ініціалізує socket.io і налаштовує його таким чином, що єдину трансляцію можна ретранслювати на необмежену кількість користувачів без будь-яких проблем з пропускною здатністю / процесором. Все відбувається однолітком!

Це безумовно слід мати можливість завершити.
Інші також можуть цього досягти: http://www.streamroot.io/

AFAIK єдиною актуальною реалізацією цього, що є актуальною та зрілою, є 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. Ось кілька зразків. Janus , Jitsi , Wowza , Red5pro , Ant Media Server

Я розробник для Ant Media Server , ми надаємо як версії для спільнот, так і для підприємств, включаючи SDK для android та iOS. Повідомте нас, чи зможемо вам якось допомогти.

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

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

Для ефективної передачі даних з телефону можна використовувати SDK GoCoder Wowza, але, на мій досвід, найкраще працює такий просунутий SDK, як StreamGears .

Я розробляю систему мовлення WebRTC за допомогою медіа-сервера Kurento . Kurento підтримує декілька видів протоколу потокового передавання, таких як RTSP, WebRTC, HLS. Це також добре працює в режимі реального часу та масштабування.

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

Сподіваюся, це допоможе.

Оскільки peer1 - це лише той, хто викликає getUserMedia (), тобто peer1 створює приміщення.

1. Отже, peer1 захоплює медіа та починає номер.
2. peer2 приєднується до кімнати та отримує потік (дані) від peer1, а також відкриває паралельне з'єднання, яке називається "peer2-з'єднання"
3. Коли peer3 приєднується до кімнати і отримує потік (дані) від peer2, а також відкриває паралельне з'єднання, яке називається "peer3-з'єднання" тощо.

Цей процес безперервно стільки ж однолітків з’єднується один з одним.

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

Нарешті, все вище, що міститься, є посиланням від Link .