Как повторно транслировать веб-камеру через сервер

Я разрабатываю решение, которое позволит передавать видео с веб-камеры, подключенной к Raspberry Pi, на мой сервер в AWS, а затем повторно передавать в браузер, обращающийся к веб-сайту на сервере AWS. Будет задействовано много Pi, и пользователь будет запускать и получать доступ к каналу, поступающему от его собственного Pi, по запросу.

Для меня это незнакомая территория, поэтому я не знаю, с чего начать, и ищу совета по лучшей архитектуре.

Пока я рассматриваю процесс (в идеале python) на каждом Pi, который откроет подключение к серверу через веб-сокет. Сервер будет отслеживать каждый сокет с точки зрения учетной записи пользователя, к которой он относится. Затем пользователь подключался к серверу, инициировал сигнал через веб-сокет, чтобы включить свой собственный видеопоток Pi, и видеопоток отправлялся на мой сервер. Их идея состоит в том, что они должны затем просматривать видеопоток через URL-адрес на моем сайте, а НЕ через URL-адрес на Pi - это решит любые проблемы с доступом к NAT.

Как я могу отправить видеопоток с каждой веб-камеры Pi на сервер, чтобы казалось, что прямой эфир поступает с самого сервера?

По сути, это то же самое, что было запрошено здесь, но не получило ответа.


video video-streaming mjpeg
person Lee Melbourne    schedule 19.06.2017    source источник
comment
Это незнакомая для меня территория, и не тратьте мое время, предлагая... действительно не следует писать в одном и том же посте. Ужасно высокомерно беспокоиться о своем времени, когда своим вопросом спрашиваешь время других.   -  person Brad    schedule 20.06.2017
comment
Дело принято. Извините за мой "багаж". Но это связано с предыдущим вопросом, который я разместил, где я указал, что переадресация портов не является подходящим решением, и затем мне задали несколько вопросов о том, почему. Когда я увидел аналогичный моему вопрос (который я предоставил в виде ссылки) с переадресацией портов, предложенной в качестве решения, которое не соответствует проблеме, это напомнило мне об этом инциденте, и я просто пытался избежать ненужного диалога в этом посте, который уже был освещается в связанном посте и (на мой взгляд) в другом. Я на самом деле не хотел быть грубым.   -  person Lee Melbourne    schedule 21.06.2017

Ответы (2)


arrow_upward
2
arrow_downward

Для ваших целей самым простым и мощным инструментом является UV4L, как упоминалось в комментариях. Помимо встроенных возможностей p2p, я бы также рассмотрел это для соединения многих одноранговых узлов: http://Rpi%20Video%20Conference%20DEMO%20OS.

По сути, это готовый к использованию образ ОС для Raspberry Pi, обеспечивающий конференц-зал для аудио/видео (спасибо Janus SFU), при загрузке которого многие Raspberry Pi (включая тот, на котором работает ОС) с подключенными камерой, микрофоном, дисплеем и динамиками или ПК, смартфоны и т. д. могут публиковать/подписываться на свое/чужое аудио или видеопотоки. Raspberry Pi под управлением ОС может в конечном итоге решить подключиться к любой видеокомнате в Интернете, как указано выше в приведенной выше ссылке, а не только к «локальной». На стороне Rpi браузер не требуется, поскольку UV4L использует все аппаратное обеспечение напрямую и имеет встроенную поддержку WebRTC (он даже поддерживает аппаратное кодирование/декодирование H264). И Janus Gateway, и UV4L можно настроить с любым заданным списком серверов STUN/TURN, и они также успешно используются с экземплярами AWS.

В UV4L есть встроенная веб-страница, делающая все вышеперечисленное возможным с помощью нескольких щелчков мыши. Однако с помощью UV4L RESTFul API (и с помощью панели для тестирования этого API) вы можете написать/настроить собственное веб-приложение для определенных целей (например, создать частную, защищенную паролем комнату с заданное количество издателей или подписчиков, соответствующих требованиям в вашем случае)

person spippulus    schedule 19.07.2017
comment
Спасибо spipulus. Насколько я понимаю, однако, если Pi использует конференц-зал UV4L за NAT, вы можете звонить оттуда, но вы не можете звонить, поскольку порт / IP-адрес Pi неизвестен и потенциально является NAT с ограниченным конусом, он не будет принимать соединение, если только оно не инициировало транзакцию. Итак, мое запланированное решение — это служба веб-сокетов на каждом Pi, подключающемся к серверу AWS. Этот сервер потребует от владельца Pi входа в систему, сопоставления входа в систему с сокетом, отправки URL-адреса Jitsi на Pi через сокет и отправки того же URL-адреса вызывающему абоненту. - person Lee Melbourne; 19.07.2017
comment
Затем установите Janus на AWS, как я уже сказал, и подключите UV4L к этому экземпляру. Не переделывайте колесо. Используйте WebRTC с TURN/STUN, чтобы помочь одноранговым узлам пройти через NAT, поскольку это стандарт, созданный для преодоления всех этих трудностей. Было бы сложно надежно реализовать все это через веб-сокеты. - person spippulus; 19.07.2017
comment
В качестве обновления к этому; Я изо всех сил пытался заставить UV4L работать с USB-камерой. Я обновлял и переустанавливал около 5 раз, чтобы попробовать разные подходы, но всегда с одним и тем же результатом: поток mjpeg на UV4L-Server работает нормально, но с параметрами WebRTC я просто получаю пустой канал камеры (но звук в порядке). Я также не получил ответа от их электронной формы до сих пор. - person Lee Melbourne; 01.04.2018

arrow_upward
1
arrow_downward

Пропустите часть, где вы транслируете через свой сервер, и просто используйте WebRTC.

Это одноранговая сеть, работающая в браузере, имеющая автоматическое согласование кодеков, обход NAT и все, что вам нужно. Все, что вам нужно для размещения, — это сервер сигнализации и сервер TURN, когда оба узла защищены брандмауэром.

person Brad    schedule 20.06.2017
comment
Спасибо, Брэд. Я думал об этом, но разве WebRTC не только между двумя браузерами? Я не буду запускать сеанс клиентского браузера на Pi, только фоновые процессы в Python. Я также понимаю, что вам нужно принять входящее соединение WebRTC через браузер, и я хочу, чтобы соединение принималось автоматически. Я тоже ошибаюсь? - person Lee Melbourne; 21.06.2017
comment
@LeeMelbourne WebRTC работает между тем, между чем вы хотите, чтобы он работал. Да, он обычно используется между браузерами, но нет причин, по которым Pi не может быть равноправным. И нет, вам не нужно принимать соединение WebRTC. Соединения WebRTC также на самом деле не являются входящим или исходящим ... есть инициатор, который отправляет первую сигнальную информацию, затем два узла договариваются, и направление, в котором они подключаются, может быть любым в зависимости от выбранного кандидата ICE. - person Brad; 21.06.2017
comment
Таким образом, кажется, что не так просто настроить сеанс WebRTC без браузера. На это сообщение не было ответа stackoverflow.com /questions/29292852/ и этот пост stackoverflow.com/ Questions/27569445/webrtc-without-a-browser указывает, что мне нужно каким-то образом использовать родные библиотеки WebRTC... что, похоже, открывает червей для кодирования. Я продолжу поиски, но мне еще предстоит найти хороший простой способ запустить процесс Python, который будет инициировать или ожидать подключения WebRTC. Похоже, это возможность, очень сильно привязанная к браузерам. - person Lee Melbourne; 27.06.2017
comment
@LeeMelbourne github.com/kclyu/rpi-webrtc-streamer linux-projects.org/2017/04/29/uv4l-webrtc- for-pizero Это не более чем банка с червями, чем должна быть. - person Brad; 27.06.2017
comment
Похоже, что многое было добавлено в UV4L. Спасибо за указатель. Давно смотрел и забыл. - person Lee Melbourne; 29.06.2017
comment
На самом деле WebRTC не обеспечивает обхода NAT. Это должно быть обеспечено ICE, STUN или TURN. (Полезное обсуждение доступно здесь webrtchacks.com/an-intro-to- webrtcs-natfirewall-problem) Я думаю, что реализация сервера для них будет более сложной, чем повторная потоковая передача видео. UV4L — это, по сути, видеодрайвер, но он предоставляет множество других утилит, включая потоковый сервер. Однако этот потоковый сервер будет находиться на Pi за NAT и, следовательно, будет недоступен. Однако ссылка на UV4L была ценной, так как привела меня к Jitsi, что я считаю жизнеспособным решением. - person Lee Melbourne; 18.07.2017
comment
@LeeMelbourne Я хорошо знаю, как работает WebRTC. Если вы снова прочитаете мой ответ, вы заметите, что я упомянул вам, как это сделать. В большинстве случаев (~88%) вам не нужен TURN. Публичные STUN-серверы предварительно настраиваются в браузерах, либо вы можете указать свои собственные. Если вы запускаете свой собственный сервер TURN, вы получаете STUN вместе с ним. В любом случае, как я уже сказал, вы не будете запускать эти серверы на Pi, вы будете запускать их в другом месте. Пис был бы одним из сверстников. Если вы думаете, что избавитесь от этого требования с Jitsi, вы ошибаетесь. Джитси и есть этот сервер. - person Brad; 18.07.2017