Развертывание многопользовательской WebRTC трансляции с web-камеры через сервер за 3 минуты

[@Anonym]

За 3 минуты и $2000

[@flashphoner]

Расчеты некорректны. Ежемесячная подписка стоит 75 usd. В месяце в среднем 720 часов, т.е. 43200 минут. Получается 0.17 центов в минуту. Тогда правильно писать так:

За 3 минуты и 0.51 цента.

или так

За 3 минуты и 30 копеек.

[@OtshelnikFm]

$95 в месяц
при оплате за год

или

$145 в месяц
при оплате за месяц

Да, разочарование по ценам. Сказали бы в самом начале что — «откройте кошельки и если они не пустые — читайте дальше».

[@devlev]

Вот я ещё в Гугл не залез но что то мне подсказывает что реализовать сервер ретранслятор можно и на node js?

[@flashphoner]

Node.js — это Websockets. Т.е. на нем можно реализовать сигналинг с обменом SDP между браузерами. WebRTC он ретранслировать не умеет.

[@VolCh]

В nodejs вы имеете доступ к хосту практически такой же как у Си программы. В частности возможность работы с сетевыми сокетами.

[@nwalker]

Успехов написать весь монструозный и неадекватныйвеликолепный и непревзойденный стек протоколов, используемый WebRTC. Кстати, стандарт требует кодировать видео отдельно для каждого пира, можно для комплекта еще и кодек на ноде заимплементить.

[@flashphoner]

Ок. Node.js может работать с native кодом и биндить порты в частности. PHP или JSP тоже умеют работать с C-кодом, но это не означает автоматической поддержки WebRTC. Есть реализация Node.js+Websockets. Там можно сделать похожий сигналинг между браузерами, но это уже P2P — немного другое, там стрим будет кодироваться отдельно для каждого зрителя, и браузер-транслятор скоро повиснет.

[@ice2heart]

Есть опенсурсная штука, называется Kurento-media-server позволяет получать и модифицировать webrtc как душе угодно, но ресурсоёмкая штукенция.

[@MKhan98]

На сегодняшний день технология WebRTC сырая, как мокрые плавки. Снижение нагрузки на сервер на 98% за счет децентрализации — гениально, но сначала надо бы всем гигантам, начиная с браузеров, заканчивая интернет-провайдерами, собраться всем месте за столом и договориться дать добро этой технологии. Иначе время на подключение между пирами будет всегда долгим и не стабильным.

[@flashphoner]

На сегодняшний день технология WebRTC сырая, как мокрые плавки.

Лет 5 назад это было так. А сегодня технология уже достаточно зрелая и работает в продакшенах. При этом P2P технология не ограничивается, можно и VOD по WebRTC раздавать при желании. И кстати да, проблемы с подключением P2P — обратная сторона децентрализации. При подключении напрямую к серверу таких проблем не возникает. Подключение проходит быстро. Все потому, что не нужно долго сканировать сеть в поисках пригодных внешних IP для приема трафика.

[@MKhan98]

Тогда чем передача потока от сервера к клиенту по WebRTC отличается от такой же передачи по Вебсокетам?
Отличия я ищу сейчас не в простоте настройки (у меня есть время на это), а в нагрузке на сервера.

[@flashphoner]

WebRTC по нагрузке в любом случае будет выше чем по Websockets. Дело в том, что там не просто льется видео, а работает много сервисов поверх потока, таких как RTCP feedback, ICE, шифрование. А основное отличие в том, что WebRTC идет по UDP с динамическим битрейтом и контролем сети и задержек, а Websockets идет по TCP и как получится. Т.е. если важно снизить нагрузку на сервер и некритична задержка, лучше использовать Websockets, если конечно получается его нормально отобразить на стороне браузера.