Трансляция/вещание живого видео по локальной сети (без VLC)

Я пытаюсь создать идеальную мобильную веб-камеру, соответствующую моим потребностям, с помощью RPI и модуля камеры, которые у меня уже есть. Я использую Arch как на RPI, так и на ноутбуке, который собираюсь использовать в качестве “клиента”. Камера работает, и я могу передавать её данные из raspivid куда-то, а также я могу подключаться по ssh.

Теперь я пытаюсь наладить передачу через локальную сеть. В идеале, я бы запустил “серверный” скрипт на RPI и смог бы подключать столько клиентов, сколько захочу, до тех пор, пока не решу закрыть сервер снова. И, в идеале, задержка от наличия отдельного устройства и беспроводной передачи была бы практически незаметной, так что мне не пришлось бы компенсировать и пытаться синхронизировать видео и аудио. Из того, что я прочитал, использование VLC — это не вариант. Также в идеале “клиент” должен сделать поток доступным как /dev/video1 или что-то подобное — хотя на данный момент я просто хочу как-то запустить это в OBS.

До сих пор я пытался следовать нескольким урокам, особенно с использованием netcat, но процесс сразу останавливался или останавливался, как только происходило отключение, поскольку я не мог воспроизвести поток на клиенте.

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

Если вы хотите транслировать видео, используйте протокол, предназначенный для потокового видео. То есть, используйте UDP и multicast, чтобы подключить столько клиентов, сколько захотите. Потому что с TCP и unicast это остановится, как только вы отключитесь, как вы уже выяснили.

Существуют такие протоколы, например, RTSP, и есть реализации серверов, такие как icecast. Это не “супер легковесно”, но должно нормально работать на RaspPi.

И нет, вы не хотите делать поток доступным как /dev/video1. Вместо этого вам следует использовать клиент, который правильно подключится к Multicast группе, а затем просто прочитает поток из сети.

Я не совсем уверен, что вы прочитали о VLC и почему это не вариант, но VLC (и большинство других видеоплееров) как клиент для RTSP потока должен работать без проблем, и не должно быть проблем с синхронизацией видео и аудио, если они транслируются синхронно (что может быть проблемой в зависимости от того, как оборудование подключено к RaspPi, но вы не упоминали ничего о вашем аудиоисточнике изначально).

Правка

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

Правка

Хорошо, я посмотрел видео (по крайней мере, начало с VLC и задержки, мне не очень нравится смотреть видео).

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

Для забавы я попробовал ffmpeg с RTP на мультикассной группе, и я также получил большую задержку (порядка 1-2 секунд с H264, плюс задержка, добавляемая ffplay). Снижение задержки — это отдельная наука и потребует много манипуляций с параметрами (и изучения их). Но наличие задержки не является признаком того, что что-то не так, наоборот.

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