Как лучше всего транслировать прямую трансляцию с веб-камеры на СЕРВЕР и обратно в Интернет? - PullRequest
0 голосов
/ 12 июля 2020

Мне нужна помощь.

Как лучше всего настроить ЖИВОЙ СТРИМИНГ через Интернет с моей ВЕБ-КАМЕРЫ на сервер и обратно для нескольких пользователей?

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

Я не хочу, чтобы оно было одноранговым webRT C.

Мне действительно удалось заставить его работать с getUserMedia () -> mediaRecorder -> ondataavailable -> передать блоки больших двоичных объектов в node.js через SOCKET.IO -> socket.io отправляет блоки больших двоичных объектов другим подключенным пользователям -> добавляет эти блоки в sourceBuffer, подключенный к источнику мультимедиа, установленному как исходный URL на

И это действительно сработало! НО он такой медленный, отрывистый и ресурсоемкий. Поскольку эти куски проходят примерно 20 в секунду, это сильно замедляет страницу. Я не думаю, что вы должны так быстро передавать столько блобов в sourceBuffer. Просто для теста я попытался сохранять mediaRecordings каждые 3 секунды (так что это не так ресурсоемко) и передавать эти веб-капли в sourceBuffer, но по какой-то причине загружается только первый веб-сайт, а другие не добавляются или не начинают играть.

Это просто не может работать для производственного приложения таким образом.

Какой «ПРАВИЛЬНЫЙ» способ сделать это?

Как передать видеопоток с веб-камеры на сервер Node.js правильно?

И как транслировать этот прямой поток обратно в Интернет с сервера Node.js, чтобы у нас мог быть групповой видеочат?

Я немного потеряно. Пожалуйста, помогите.

Я использую HLS? RecordRT C?

Могу ли я транслировать из Node.js через http или через socket.io?

Существуют службы, которые уже позволяют вам делать это легко, например vonage video api tokbox, но они кажутся быть очень дорогим?

Я хочу запустить потоковое видео через мой собственный Node.js сервер, который я контролирую.

Как лучше всего это сделать?

Пожалуйста помогите.

Спасибо

1 Ответ

1 голос
/ 12 июля 2020

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

Я не хочу, чтобы оно было одноранговым webRT C.

Видеочат требует низкой задержки и, следовательно, требует использования WebRT C. Помните, что один из «пиров» на самом деле может быть сервером.

И это действительно сработало! НО это так медленно, с задержками и потребляет много ресурсов.

Кодирование / декодирование видео требует значительных ресурсов независимо от того, как вы это делаете. Если под «медленным» и «запаздывающим» вы подразумеваете высокая задержка , тогда да, запись фрагментов, отправка фрагментов, декодирование фрагментов будут иметь более высокую задержку по самой своей природе. Кроме того, то, что вы описываете, не будет отбрасывать кадры или динамически настраивать кодировку, поэтому, если соединение не может поддерживать, оно просто будет буферизоваться, пока не сможет. Это другой вид компромисса, чем то, что вы хотите.

Опять же, для видеочата реальность в реальном времени важнее качества и надежности. Если это означает отбрасывание кадров, тупо-быструю передискретизацию звука, кодирование с низким битрейтом, даже временное полное отключение потоков на несколько секунд, вот что должно произойти. Это то, что делает весь стек WebRT C.

Поскольку эти фрагменты передаются со скоростью 20 в секунду, это сильно замедляет страницу. Я не думаю, что вы должны так быстро передавать такое количество BLOB-объектов в sourceBuffer.

Нет, это вряд ли ваша проблема. Принимающая сторона, вероятно, просто не может справиться с декодированием всех этих потоков.

Я использую HLS?

Не для тех, кто активно участвует в чате ... люди, которым требуется низкая задержка. Для всех остальных, да, вы можете использовать HLS и DA SH, чтобы предоставить вам более доступный способ распределения вашего потока по существующим CDN. См. Этот ответ: { ссылка } По сути, внимательно изучите свои требования и определите, все ли на самом деле участвуют. В противном случае переместите их на более дешевый метод потоковой передачи, чем WebRT C.

RecordRT C?

Нет, это не имеет отношения к вашему проекту и, честно говоря, я не знаю, почему люди продолжают использовать эту библиотеку для чего-либо. Возможно, у них есть какой-то конкретный c вариант использования, о котором я не знаю, но браузеры уже много лет имеют встроенный MediaRecorder .

Есть службы, которые уже позволить вам сделать это легко, как vonage video api tokbox, но это кажется очень дорогим?

Это дорогое удовольствие. Я думаю, вы обнаружите, что использование существующей службы, в которой уже есть инфраструктура, готовая к go, в большинстве случаев будет дешевле, чем делать это самостоятельно.

...