Как ввести изображение с IP камеры?

[MiK13]

Начальник где-то достал IP камеру (по некоторым данным blk16ev2-0307) и хочет, чтобы мы научились вводить с неё изображение и показывать его в своей программе с некоторой обработкой.
Для винды есть какая-то программа, с названием CMS (как я понимаю, из системы охранного наблюдения), которая вводит с неё изображение и показывает на экране. Может показывать на экране до 64 картинок.
Но он требует, чтобы была программа с исходным текстом. Чтобы встроить приём в нашу программу.
В качестве "подсказки" нашёл zoneminder. Но это большой пакет для охранных систем и я пока даже не разобрался как его настроить для приёма.
В одном видео есть рекомендация использовать vlc, в нём ввести команду типа rtsp://<IP>/stream=0, но такой ввод ничего не даёт; выскакивает сообщение что "источник не открывается"
Сама камера имеет 5 открытых портов TCP (wk определил через /etc/hosts):

Shell

$ nmap wk -p1-65000
Starting Nmap 7.80 ( https://nmap.org ) at 2024-04-30 12:04 +03
Nmap scan report for wk (192.168.1.40)
Host is up (0.023s latency).
Not shown: 64995 closed ports
PORT STATE SERVICE
80/tcp open http
554/tcp open rtsp
8000/tcp open http-alt
8899/tcp open ospf-lite
34567/tcp open dhanalakshmi

Nmap done: 1 IP address (1 host up) scanned in 4.14 seconds

Для получения данных используется порт 34567.
При попытке зайти браузером появляется на пустом экране кнопка с предложением загрузить и установить VideoPlayTool по которой скачивается VideoPlayToolSetup.exe. Что с ним делать, не знаю.

Как мне подступиться к данной проблеме?

[semiconductor]

Не это?

[Aliech]

Ну так это, посмотрите как "CMS" получает с камеры данные. Запустите wireshark на соседней машине и посмотрите, как там CMS запрашивает стрим (подключается по rtps), как потом камера "отгружает" видео по rtp.

[MiK13]

Ну так это, посмотрите как "CMS" получает с камеры данные. Запустите wireshark на соседней машине и посмотрите, как там CMS запрашивает стрим (подключается по rtps), как потом камера "отгружает" видео по rtp.

Я хотел посмотреть tcpdump'ом, подключив к тому же свичу, что и камера, но он ничего не показал. Видимо свич направляет поток на конкретный порт.
Wireshark запускал на той же машине. Но, похоже поймал не всю сессию. Увидел только обмен по порту 34567. А RTSP это обычно 554. Ещё там были ARP запросы на адрес ...1, причём как от винды, так и от камеры.
Завтра попробую сначала запустить "акулу", а потом CMS и записать весь трафик.

[ormorph]

Там ещё параметры разные нужно задавать к IP.

Код: Выделить всё

#netcam_url rtsp://yourcamera1ip:port/camera/specific/url
#netcam_url rtsp://<IP>/user=admin&password=&channel=1&stream=1.sdp
#netcam_url rtsp://<IP>:34567/user=admin&password=&channel=1&stream=1.sdp
#netcam_url rtsp://<IP>/user=admin_password=_channel=1_stream=0.sdp

Так что если вычислили IP не факт что с тем параметром у вас заработает.
Например у меня работает только этот последний пример:

Shell

mpv rtsp://<IP>/user=admin_password=_channel=1_stream=0

Что с .sdp в конце, что без работает одинаково работает. Ваш пример у меня не работает.

[ormorph]

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

Shell

$ nmap --script rtsp-url-brute -p <IP> |awk '{print $2}'|grep 'rtsp://'| xargs -i mpv {}

Так как у вас уже найден доступный IP осталось дело за малым.

[Aliech]

А RTSP это обычно 554.

RTSP - это управление. Не сам поток. Обращаясь по RTSP, ваш компьютер запрашивал с камеры поток "на такой-то адрес, в таком то формате и качестве". После чего камера начала отгружать видео, пожатое каким-то кодеком, на какой-то адрес:порт. И всё это в виде RTP-пакетов, что вы и наблюдали:

Увидел только обмен по порту 34567.

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

Нормальный свитч. Так и надо. Раньше чипы в свитчах были тупее, потому банальное выставление порта в promisc (как и делает tcpdump) приносило трафик. Отсюда вывод: нужно собрать комп с двумя сетевухами, чтобы его ставить "в разрыв", и на нём уже дампить трафик.

И да, в вашем случае есть ещё вероятность того, что свитч умел multicast, а камера/софт его успешно запрашивали. Для потокового видео так делают, чтобы потом, когда будет более одного получателя трафика (более одного клиента у камеры), два раза пакеты с камеры не отгружать.

[MiK13]

Там ещё параметры разные нужно задавать к IP.

Код: Выделить всё

#netcam_url rtsp://yourcamera1ip:port/camera/specific/url
#netcam_url rtsp://<IP>/user=admin&password=&channel=1&stream=1.sdp
#netcam_url rtsp://<IP>:34567/user=admin&password=&channel=1&stream=1.sdp
#netcam_url rtsp://<IP>/user=admin_password=_channel=1_stream=0.sdp

Не понял что такое netcam_url. Программы такой не нашёл. Яндекс отправил к motion, но и там не было такого файла

Например у меня работает только этот последний пример:

Shell

mpv rtsp://<IP>/user=admin_password=_channel=1_stream=0

Запустил. Действительно заработал. На экране появилась картинка.
Но если с CMS задержка было примерно 0.3 секунды, то тут примерно 2
По данным top vlc] загружает процессор немногим больше 400%, загрузка потоков различается мало
При этом слышен какой-то шум. Сначала подумал, что это шум вентилятора, но это дополнительный шум: при закрытии mpv он пропадает.
Так же пропадает при Mute.
С vlc получить картинку пока не удалось

Непонятно другое.
Подключил камеру к свичу и к нему же ноутбук с Debian 11 и моноблок с виндой.
На винде запустил CMS и WireShark. А потом ещё и пробную весию tcpdump.exe
На ноутбуке mpv rtsp://192.168.1.153/user=admin_password=_channel=1_stream=0
Что непонятно:
В винде как Wireshark, так и tcpdump.exe показывают обмен только по порту 345678
На ноутбуке tcpdump -n показывает обмен только по порту 554.

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

Shell

$ nmap --script rtsp-url-brute -p <IP> |awk '{print $2}'|grep 'rtsp://'| xargs -i mpv {}

Зашёл по ссылке, увидел там Download. Но то, что там, на скрипт не очень похоже.

Добавлено (16:40):

Обнаружил, что если задать mpv --rtsp-transport=udp rtsp://..., то камера начинает выдавать данные по протоколу UDP, а не TCP.

[ormorph]

Зашёл по ссылке, увидел там Download. Но то, что там, на скрипт не очень похоже.

Да нет это скрипт и он рабочий, я его уже пробовал. С остальным всё тоже самое.

[MiK13]

Зашёл по ссылке, увидел там Download. Но то, что там, на скрипт не очень похоже.

Да нет это скрипт и он рабочий, я его уже пробовал. С остальным всё тоже самое.

По этой ссылке загружается файл rtsp-url-brute.nse, который на скрипт не похож.
В начале скрипта обычно идёт "шебанг" (#!), а тут его нет.
Да и про команду local, с которых начинается этот файл, bash выдаёт, что они могут только внутри функций использоваться.

Может быть сам скрипт где-то внутри этого файла?

[ormorph]

Может быть сам скрипт где-то внутри этого файла?

Не это скрипт используемый nmap и называется rtsp-url-brute.nse. Я же даже дал пример команды:

Shell

$ nmap --script rtsp-url-brute -p <IP>

Тут как раз nmap обрабатывает с помощью этого скрипта. Просто расширение .nse, не надо прописывать. Просто скачайте этот скрипт и в каталоге со скриптом выполните эту команду.

[MiK13]

Может быть сам скрипт где-то внутри этого файла?

Не это скрипт используемый nmap и называется rtsp-url-brute.nse. Я же даже дал пример команды:

Shell

$ nmap --script rtsp-url-brute -p <IP>

Тут как раз nmap обрабатывает с помощью этого скрипта. Просто расширение .nse, не надо прописывать. Просто скачайте этот скрипт и в каталоге со скриптом выполните эту команду.

Действительно всё прошло. И выдало 188 строк.
Кроме основной,
rtsp://10.177.11.201/user=admin_password=tlJwpbo6_channel=1_stream=0.sdp?real_stream
Ещё 175 строк в которых после адреса шло что-то ещё. Но как это использовать, я не понял.
Пытался вставлять перед /user=... -- ни на что это не влияет.
И ещё непонятна ситуация с паролем.
nmap выдал, что пароль должен быть "tlJwpbo6". В ответ на любой другой выдаёт "401 Unauthorized". Но пустой воспринимает.

Но всё это "не то".
Попробовал другие плееры. С vlc ничего не получается. А вот totem и gst123 запустились.
Но проблема одна и та же. Задержка около двух секунд. А начальника не устраивает даже задержка 0.3 секунды, которую даёт программа CMS. Как я понял, он хочет максимум 0.15
И непонятно, что за порт 34567, "dhanalakshmi", по которому работает CMS

[Bizdelnick]

Задержка около двух секунд.

Ну так покрутите настройки буферизации в плеере.

Добавлено (22:10):

Как я понял, он хочет максимум 0.15

У Вас какие-то странные отношения с начальником, если Вы не уверены, что правильно поняли даже такое простое ТЗ.

[Aliech]

MiK13, если вы хотите минимальных задержек, то учитесь запрашивать RTP-стрим поверх UDP. А после того, как научитесь запрашивать по RTSP правильный стрим на себя, вам придётся ещё и сетевой стек потюнить (кеши и очереди), а может даже и jumbo-фреймы применить.

И да, если камера умеет отдавать видео хотя бы в H264, то это было бы плюсом. Он не тяжёлый. Во всех смыслах. И клиент не умрёт при декодировании, и меньше проблем с тюнингом сетевого стека будет.

Вообще видео гонять - только на первый взгляд простая задача. Как только там появляются какие-то требования, чуть больше чем "просто картинку увидеть", дело это из плёвой задачи, решаемой почти любым плеером, перерастает в серьёзную работу. Где и с камерой работать придётся научится, и разобраться в тонкостях тюнинга сетевого стека Linux, разобраться в особенностях применения ffmpeg или GStreamer'а.

Но если пройти эти этапы, то 0.3 секунды точно преодолеете.

[MiK13]

MiK13, если вы хотите минимальных задержек, то учитесь запрашивать RTP-стрим поверх UDP. А после того, как научитесь запрашивать по RTSP правильный стрим на себя, вам придётся ещё и сетевой стек потюнить (кеши и очереди), а может даже и jumbo-фреймы применить.

Я и хочу разобраться с протоколом, чтобы знать как управлять камерой, запрашивать у неё данные.
Но начальник говорит, что незачем разбираться с протоколом, нужно просто найти программу, которая под линуксом может принимать с неё данные и чтобы были доступны исходники. Нашёл XEOMA, но с неё подключиться к камере не удалось. Что-то ещё находили, но получить картинку не удалось.
По словам начальника в камере Linux (при пинге TTL=64, периодически идут ARP запросы на адрес x.x.x.1, когда добавлял этот адрес к своему компьютеру, видел запросы на (по данным whois) китайские адреса. "Аппаратчики" говорили, что подключались к камере по RS-порту, но при включении питания видны только сообщения о загрузке)
Принимать данные по UDP, надеюсь, проблем не будет. Основная проблему будет сформировать из них кадр.

И да, если камера умеет отдавать видео хотя бы в H264, то это было бы плюсом. Он не тяжёлый. Во всех смыслах. И клиент не умрёт при декодировании, и меньше проблем с тюнингом сетевого стека будет.

Камера, похоже, выдаёт по H264 (вроде может и по H265).
Если картинка (FullHD) статическая, mpv говорит, что Bitrate в раёоне 440 kbps (±5). Когда начинал махать руками (я в кадре) битрейт поднимался выше 1000 kbps. Так что предстоит ещё разбираться с библиотеками распаковки.

Вообще видео гонять - только на первый взгляд простая задача. Как только там появляются какие-то требования, чуть больше чем "просто картинку увидеть", дело это из плёвой задачи, решаемой почти любым плеером, перерастает в серьёзную работу. Где и с камерой работать придётся научится, и разобраться в тонкостях тюнинга сетевого стека Linux, разобраться в особенностях применения ffmpeg или GStreamer'а.

Похоже, что начальник пока этого не понимает.

Ради интереса в команде заменил mpv на ffmpeg -i и указал выходной файл.mp4. Через 40 секунд прервал. mpv его проигрывает, говорит, что Video: h264 (H264 / AVC / MPEG-4 AVC / MPEG-4 part 10)
Если запускаю прямо в mpv, то Video: hevc (HEVC (High Efficiency Video Coding))

[Bizdelnick]

нужно просто найти программу, которая под линуксом может принимать с неё данные

Так нашли ведь уже кучу. Остановитесь и

покрутите настройки буферизации

[MiK13]

покрутите настройки буферизации

Знать бы какие крутить...
У mpv масса самых разных опций. Я пробовал задавать разные со значениями сильно отличающимися от дефолтных. Но влияния на задержку не заметил.
Вообще стал подозревать, что изображение принимает не сама программа, а система v4l и крутить настройки надо там.

[Bizdelnick]

У mpv масса самых разных опций. Я пробовал задавать разные со значениями сильно отличающимися от дефолтных. Но влияния на задержку не заметил.

man mpv читали? Там целый раздел про задержку есть. TL;DR: mpv --profile=low-latency.

[MiK13]

man mpv читали?

Читал. Но он слишком большой, чтобы быстро во всём разобраться,

Там целый раздел про задержку есть. TL;DR: mpv --profile=low-latency.

Я в основном про буфера смотрел. Про латентность как-то не подумал.
Но это опция хоть и помогла, но только частично -- задержка уменьшилась примерно до пол секунды.
Думаю ещё opencv попробовать.

[Bizdelnick]

задержка уменьшилась примерно до пол секунды.

По TCP или по UDP?

[MiK13]

задержка уменьшилась примерно до пол секунды.

По TCP или по UDP?

Я последний раз проверял по UDP. Потом камеру забрали, чтобы что-то другое проверять.
Сравнить UDP и TCP смогу только в среду.

Дома пытался экспериментировать с другим устройством, но это отдельная тема.