Потоковая передача видео с клиента на сервер: какое альтернативное использование, websocket или webrtc

Я желаю сделать несколько небольших проектов, экспериментирующих с потоковой передачей видео и аудио от клиента к серверу и от точек с множественными номерами клиент-сервер, у меня есть несколько вопросов:

1) Я знаю, что это не так сложно потоковое воспроизведение от точки к точке, избегая середины сервера, используя webrtc, но возможен поток клиента на сервер с использованием webrtc (существуют некоторые преимущества, выполняемые над websocket, или преимущество в webrtc - избежать средней связи)... как насчет потокового видео и аудио?

Потоковое видео или аудио с помощью websocket действительно просто, но я не могу найти никакого опыта по потоковому клиенту-серверу с помощью webrtc.

2) Как насчет потокового видео для кратных точек, я знаю, чем недавно были некоторые эксперименты с webrtc, потому что изначально это было невозможно, теперь: производительность webrtc ухудшается, когда она используется для 1-х многих точек?... была бы лучшая идея потоковой передачи на сервер (возможно, с использованием webrtc), а затем потоковая передача в несколько точек с помощью websockets??.

Большое спасибо и, пожалуйста, не грубите, мой вопрос не соответствует или сравнивает обе технологии, больше связан с тем, какие ограничения и где я могу использовать каждый... спасибо!

Ответ 1

Peer2Peer?

Может быть сделано с помощью WebRTC, а не с помощью WebSockets. См. Разрешено ли веб-сайтам для обмена сообщениями p2p (браузер в браузере)?

Поддержка браузера?

WebRTC: Chrome + Firefox (+ Opera)

WebSockets: Chrome + Firefox + IE + Safari (+ Opera и некоторые другие)

Транспорт?

WebRTC: UDP (SRTP) (также возможно: режим TCP с сервером TURN), надеюсь, всегда будет сквозным зашифрованным, но Я не уверен в случае серверов TURN

WebSockets: TCP, может быть защищен через HTTPS/WSS, но не сквозным между одноранговыми узлами!

Ответ 2

Да, возможно...

попробуйте использовать KURENTO с WEBRTC.

Вы можете найти приложения "от одного до многих" в своей документации, от клиента к серверу и серверу до многих клиентов.

Ответ 3

WebRTC создан для браузеров. Вы сказали это правильно:

или преимущество в webrtc - избежать средней связи

Это особенно сделано для браузеров. Вы можете установить соединение с вашим сервером, но тогда он должен иметь пользовательский интерфейс (ubuntu-сервер с графическим интерфейсом) и установить браузер (но это не то, что вы хотите, я думаю). Рядом с этим нет другого способа для потоковой передачи на ваш сервер, чем websockets.

В соответствии с другим ответом можно передавать на серверы с поддержкой RTC и с них

О нескольких потоках, но это сложно. я ответил на вопрос об использовании webrtc как множественного однорангового узла. Возможно, это то, что вы можете сделать, но для этого потребуется хорошее управление кодом, которое должно подключиться к кому и просто подключить ваших пользователей. Сервер в этом случае лучший (и если вы хотите пойти с совместимостью браузера, веб-порты немного более поддерживаются, чем webRTC, даже IE поддерживает их сейчас (?!?!).

Вы можете сделать вывод:

Уменьшить нагрузку на сервер, одноранговое соединение: webRTC
Несколько подключенных пользователей: WebSockets с промежуточным сервером.

Обратите внимание, что webRTC требует обмена данными, прежде чем он начнет работу. Вы можете сделать это с сервером websocket в node.js.

Надеюсь, это поможет вам в дальнейшем в вашем процессе разработки, и я надеюсь услышать от вас, какое решение вы собираетесь использовать!

Ответ 4

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

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

Итак, чтобы ответить на ваши вопросы: WebRTC лучше, чем WebSockets для потокового медиаконтента, по очевидным причинам.

Были созданы WebSockets для установления TCP-соединения с сервером, так что вы можете иметь двухстороннее соединение.
WebRTC устанавливает соединение с любым другим одноранговым узлом (а не только с серверами) и, самое главное, использует протокол SRTP (Secure Real Time Protocol) для передачи медиаконтента. Как видно из названия, протокол был создан для передачи информации в режиме реального времени, и он предпочтительно превосходит UDP. В дополнение, многие точки в сетях будут рассматривать RTP как привилегированный протокол.

Итак, преимущества очевидны, но да, вы также можете использовать WebSockets для потоковой передачи данных.

Я не могу найти никакого опыта по потоковому клиенту-серверу с помощью webrtc.

Хорошо, WebRTC использует стандартные протоколы, и вы можете использовать стандартные серверы для его поддержки. Сделайте небольшой поиск по Asterisk + WebRTC.

Относительно многоточечного вопроса, ответ тот же. У вас лучшие результаты с WebRTC (переход на сервер или нет). Как вы сказали, проблемы с одноранговой конференцией известны, и решение для этого - действительно использовать сервер для уменьшения количества потоков на один на каждого клиента. В идеальном мире вы будете использовать MCU для выполнения этой работы. Вот как это делается.

Ответ 5

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

Я лично использовал Node.js в сочетании со следующим подключаемым модулем для Node.js, чтобы включить WebRTC со стороны сервера: node-webrtc. Он поддерживался только для Linux и Mac OSX прямо сейчас, но это позволило мне быстро настроить сервер WebRTC. Затем вы можете использовать сервер для распространения потока для других одноранговых узлов, подключенных с помощью WebSockets, WebRTC или чего-то еще.

Исходный код также свободно доступен на веб-странице WebRTC. Таким образом, вы можете самостоятельно создать собственное приложение, которое будет работать как сервер, если вы хотите.