Для WebRTC транспорт по умолчанию — UDP (хотя и TCP можно, но это дает задержку и сводит на нет преимущества протокола), причем, в отличие от однопортовых RTMP и RTSP, заранее неизвестно, на какой именно порт подключится клиент. Отсюда и танцы сложности в настройке.
Это разумно. Но бывают и те, кто любит микросервисы, и, соответственно, используют докер для WebRTC и в продакшне. Для того и сделана пометка: одна чат-комната — один контейнер.
Не совсем так. Статья про WebRTC в докере. И да, на примере WebCallServer, хотя с той же Wowza проблемы с настройкой сети в докере будут ровно теми же, так что рекомендации можно применить к любому медиасерверу с поддержкой этого протокола.
Yes, you can for example use Youtube Events and create a different translation for each camera. In this case, every translation will have its own RTMP ingest point.
Another option is to use stream mixer. You can mix all the camera streams to one, and use one Youtube RTMP ingest point. Please read this step-by-step example of stream mixing. The mixer stream can be republished to Youtube just like described in this article above.
Actually, RTSP and WebRTC streaming are different cases.
RTSP is used to capture a stream from source which supports this protocol (the most of IP cameras and NVRs). It (almost) strictly describes signaling, so it's easy to implement in hardware devices.
WebRTC is used to publish stream from webcam (or mobile device camera) with a minimal latency. It requires a lot of client resources due to traffic encryption, and does not give a clear signaling definition, so different WebRTC implementations are not compatible to each other. That's besause WebRTC is not widely used in hardware devices like IP cameras. May be Google will standartize it in future.
С WebRTC источником проблема в том, что вы не можете контролировать генерацию ключевых кадров в стриме, а HLS чанки режутся по ключевым кадрам.
Поэтому мы не можем задать точное время чанка. Мы можем указать, например «не менее 2 секунд». В этом случае мы дождемся от Хрома по WebRTC ключевого кадра, проверим прошло ли две секунды, и если прошло, то нарежем чанк.
Мы не можем принудить браузер высылать ключевые фреймы в жестком интервале 2 секунды. Но можем каждые две секунды просить у браузера ключевой кадр через PLI фидбэк, и для этого есть специальная настройка. Браузер может дать, а может и не дать по запросу. Чаще дает.
Поэтому, в общем случае, без транскодинга, мы можем управлять только нижней границей длины HLS чанка.
В любом случае, уменьшение длины чанков не спасает внутри CDN, а с одним сервером такой проблемы нет. Вне зависимости от размера чанков, даже если бы мы транскодировали поток и нарезали чанки по 1 секунде, в CDN между запросом плей листа и доставкой потока с Origin-сервера пройдет время и плеер перестанет играть поток. Поэтому пока рабочий вариант — только прелоадер первому зрителю.
вещать с произвольного источника, скажем ffmpeg, прямо в браузер?
или можно напрямую дать WebRTC в зубы ссылку на RTP поток принимать без посредников?
Если смотреть на эту задачу с точки зрения сети, то получается так:
Допустим на одном компьютере 192.168.1.10 у вас ffmpeg и он умеет WebRTC (не знаю так ли это, не тестировали), но допустим, ffmpeg умеет вести себя как Chrome и является WebRTC-пиром.
Допустим на втором компьютере 192.168.1.11 установлен Chrome (WebRTC-браузер).
Чтобы «вещать прямо в браузер», вам нужно видеотрафик так или иначе передать с устройства 192.168.1.10 на 192.168.1.11 по TCP или UDP протоколу.
Тогда браузер сможет принять видеопоток, декодировать и отобразить в плеере и вещание состоится.
Чтобы передать трафик, нужно открыть как минимум 1 порт и там и там.
Допустим, передавать будем по UDP и открываем порты .10:3310 и .11:3311 соответственно.
Ок, порты забиндили. Теперь эти два устройства должны друг другу как-то сообщить о своих портах. И здесь два варианта:
Использовать третье устройство — посредник, через которого можно обменяться информацией о портах.
Сделать этим посредником условный ffmpeg.
После того, как устройства .10 и .11 обменялись портами, у них есть все необходимое для установки соединения и передачи трафика.
Т.е. ответ на вопрос — да, можно вещать напрямую из источника в браузер.
Для этого источник должен:
1) Поддерживать WebRTC-стек.
2) Выступать сигнальным сервером для обмена SDP (портами).
3) Кодировать видео один раз и тиражировать браузерам копии.
Фактически, ваш источник должен быть сервером, умеющим захватывать сырое видео с камеры, подцепленной к нему через USB или другой интерфейс.
Понятно что такое вещание будет нормально работать только внутри локальной сети, т.к. если потоков тиражируется много, то они просто не пролезут в глобальную сеть. Т.е. из локальной сети вы сможете вытащить ну 10 толстых потоков на 10 браузеров снаружи, и на этом все.
Поэтому для общего случая и для продакшена рабочий вариант — доставить поток на внешний сервер и оттуда этот поток уже распространять по браузерам. В локальной сети тоже самое, только сервер устанавливается локально.
у себя на Linux — см системные требования. рекомендуем Centos 7 или Ubuntu 18.04, как стабильность, проверенную временем и дорогами. Java рекомендуем 8 или 12.
на Windows — только в каком-либо гипервизоре, в WSL тоже должно работать.
Есть. Только не протокол, а формат. И даже в виде RFC tools.ietf.org/html/rfc6184.
Спецификация подробно расписывает как должны формироваться RTP видео пакеты для передачи по сети и как должны распаковываться. Собственно IP камеры по этой спецификации и работают (в идеальном мире) — пакуют по ней видео и заворачивают в TCP. Плееры получают и депакетизируют. Т.е. ничего не мешает паковать и заворачивать в Websockets. Только на JavaScript/TypeScript будет парсить тяжеловато чтобы спустить в MSE. Т.е. стандарт как-бы есть и можно использовать, но слишком тяжелый — легче реализовать упрощенный формат.
Путаницы нет. Внизу под обоими протоколами HTTP и Websockets работает ровно один протокол — TCP. И сравнение в скорости доставки идет между этими двумя протоколами. В случае HTTP — Request Response, в случае Websocket — поток текстовых сообщений. Второй способ быстрее, несмотря на то, что оба TCP.
Хороший вопрос.
В двух словах: поток по определенному ключу могут смотреть столько пользователей, скольким Вы раздадите этот ключ.
Теперь подробнее. Workflow выглядит примерно так:
1. ACL ключи назначаются на поток с бэкенда, и назначаются на Origin сервере
2. Пользователь (точнее, фронтенд) авторизуется на бэкенде и получает от бэкенда ключи для доступа к потокам, которые ему позволены (например, оплачены).
3. Пользователь (точнее, фронтенд) устанавливает соединение с Edge сервером, отправляет ключи, запрашивает поток и играет его.
Т.е. вся логика биллинга должна быть реализована на бэкенде, сама CDN о ней ничего не знает и не должна знать, ее дело — раздать потоки в соответствии с заданными ограничениями.
За более подробной информацией можете обратиться на наш форум. Расскажем, покажем.
Да, есть форум на сайте для общения с клиентами и в качестве публичного баг-трекера. Есть специальная тема, где мы публикуем список разработчиков, имеющих опыт внедрения.
Есть разного размера клиенты, которые давно и успешно используют Web Call Server, но, к сожалению, далеко не все из них готовы делиться своими историями, по разным причинам. Поэтому мы делимся своими, и за каждой статьей стоит реальный кейс, а то и не один.
танцысложности в настройке.Another option is to use stream mixer. You can mix all the camera streams to one, and use one Youtube RTMP ingest point. Please read this step-by-step example of stream mixing. The mixer stream can be republished to Youtube just like described in this article above.
RTSP is used to capture a stream from source which supports this protocol (the most of IP cameras and NVRs). It (almost) strictly describes signaling, so it's easy to implement in hardware devices.
WebRTC is used to publish stream from webcam (or mobile device camera) with a minimal latency. It requires a lot of client resources due to traffic encryption, and does not give a clear signaling definition, so different WebRTC implementations are not compatible to each other. That's besause WebRTC is not widely used in hardware devices like IP cameras. May be Google will standartize it in future.
Поэтому мы не можем задать точное время чанка. Мы можем указать, например «не менее 2 секунд». В этом случае мы дождемся от Хрома по WebRTC ключевого кадра, проверим прошло ли две секунды, и если прошло, то нарежем чанк.
Мы не можем принудить браузер высылать ключевые фреймы в жестком интервале 2 секунды. Но можем каждые две секунды просить у браузера ключевой кадр через PLI фидбэк, и для этого есть специальная настройка. Браузер может дать, а может и не дать по запросу. Чаще дает.
Поэтому, в общем случае, без транскодинга, мы можем управлять только нижней границей длины HLS чанка.
В любом случае, уменьшение длины чанков не спасает внутри CDN, а с одним сервером такой проблемы нет. Вне зависимости от размера чанков, даже если бы мы транскодировали поток и нарезали чанки по 1 секунде, в CDN между запросом плей листа и доставкой потока с Origin-сервера пройдет время и плеер перестанет играть поток. Поэтому пока рабочий вариант — только прелоадер первому зрителю.
Если смотреть на эту задачу с точки зрения сети, то получается так:
Допустим на одном компьютере 192.168.1.10 у вас ffmpeg и он умеет WebRTC (не знаю так ли это, не тестировали), но допустим, ffmpeg умеет вести себя как Chrome и является WebRTC-пиром.
Допустим на втором компьютере 192.168.1.11 установлен Chrome (WebRTC-браузер).
Чтобы «вещать прямо в браузер», вам нужно видеотрафик так или иначе передать с устройства 192.168.1.10 на 192.168.1.11 по TCP или UDP протоколу.
Тогда браузер сможет принять видеопоток, декодировать и отобразить в плеере и вещание состоится.
Чтобы передать трафик, нужно открыть как минимум 1 порт и там и там.
Допустим, передавать будем по UDP и открываем порты .10:3310 и .11:3311 соответственно.
Ок, порты забиндили. Теперь эти два устройства должны друг другу как-то сообщить о своих портах. И здесь два варианта:
После того, как устройства .10 и .11 обменялись портами, у них есть все необходимое для установки соединения и передачи трафика.
Т.е. ответ на вопрос — да, можно вещать напрямую из источника в браузер.
Для этого источник должен:
1) Поддерживать WebRTC-стек.
2) Выступать сигнальным сервером для обмена SDP (портами).
3) Кодировать видео один раз и тиражировать браузерам копии.
Фактически, ваш источник должен быть сервером, умеющим захватывать сырое видео с камеры, подцепленной к нему через USB или другой интерфейс.
Понятно что такое вещание будет нормально работать только внутри локальной сети, т.к. если потоков тиражируется много, то они просто не пролезут в глобальную сеть. Т.е. из локальной сети вы сможете вытащить ну 10 толстых потоков на 10 браузеров снаружи, и на этом все.
Поэтому для общего случая и для продакшена рабочий вариант — доставить поток на внешний сервер и оттуда этот поток уже распространять по браузерам. В локальной сети тоже самое, только сервер устанавливается локально.
и дорогами. Java рекомендуем 8 или 12.на Windows — только в каком-либо гипервизоре, в WSL тоже должно работать.
Можно и на обычный сервер установить, но придется чуть дольше повозиться.
Спецификация подробно расписывает как должны формироваться RTP видео пакеты для передачи по сети и как должны распаковываться. Собственно IP камеры по этой спецификации и работают (в идеальном мире) — пакуют по ней видео и заворачивают в TCP. Плееры получают и депакетизируют. Т.е. ничего не мешает паковать и заворачивать в Websockets. Только на JavaScript/TypeScript будет парсить тяжеловато чтобы спустить в MSE. Т.е. стандарт как-бы есть и можно использовать, но слишком тяжелый — легче реализовать упрощенный формат.
В двух словах: поток по определенному ключу могут смотреть столько пользователей, скольким Вы раздадите этот ключ.
Теперь подробнее. Workflow выглядит примерно так:
1. ACL ключи назначаются на поток с бэкенда, и назначаются на Origin сервере
2. Пользователь (точнее, фронтенд) авторизуется на бэкенде и получает от бэкенда ключи для доступа к потокам, которые ему позволены (например, оплачены).
3. Пользователь (точнее, фронтенд) устанавливает соединение с Edge сервером, отправляет ключи, запрашивает поток и играет его.
Т.е. вся логика биллинга должна быть реализована на бэкенде, сама CDN о ней ничего не знает и не должна знать, ее дело — раздать потоки в соответствии с заданными ограничениями.
За более подробной информацией можете обратиться на наш форум. Расскажем, покажем.
Есть разного размера клиенты, которые давно и успешно используют Web Call Server, но, к сожалению, далеко не все из них готовы делиться своими историями, по разным причинам. Поэтому мы делимся своими, и за каждой статьей стоит реальный кейс, а то и не один.