Видеорегистратор своими руками linux
Добавил пользователь Skiper Обновлено: 19.09.2024
Интересует вопрос организации видеорегистратора на базе ПК с ОС Linux.
0. Интерфейс оператора НЕ ВЕБ (это я про ZM и Avr!). Т.е. решение в любом случае должно быть заточено так, чтобы из системы было убрано всё ненужное (по сути должно остаться ядро + обвязка необходимых либ и утилит + ПО). И разумеется оператор должен быть ограничен своей ролью.
1. Сохраняет на дисках видео как есть, без перепаковки (и изменения размера понятно - в планах может быть подключение камер с разрешением до 5МП)?
2. Позволяет отображать на дисплее оператора (на том же ПК) видео в оригинальном размере (в пределах разрешения дисплея понятно, до 1920x1080)?
3. Есть ли API для расширения функционала извне? Спецификации для ознакомления доступны?
4. Поддерживаемые марки камер?
5. Управление с ленивчика?
Вот, как-то так наверное.
p.s. Кто-нибудь что-нибудь слышал о ПО OSSirius DVR 301 (Pandora 5/Pandora 11)? Авторы говорят, что именно то, что мне нужно, но ни внятных спеков, ни демок - ничего нет. Поиск тоже выдаёт инфы чуть - и как-то стремнвато покупать кота в мешке. Декларируют, что система (или по крайней мере часть) под GNU лицензируется. Хочется услышать отзывы (если они есть).
Добрый тебе совет: сделай видеосервер на оффтопике. На крайний (религиозный или ТЗ) случай возьми видеорегистратор на базе Linux (минусы: низкая ремонтопригодность, плохая масштабируемость, сложности с интеграцией). На данный момент виндовые решения на голову выше.
0. man триплексный режим, в любой системе можно пускать только клиент АРМ и оставить оператору только мышь
2. программа должна уметь разные настройки разрешения для записи/отображения
3. обычно нужный модуль делает (бесплатно) производитель по запросу проектно-монтажных организаций. на них же и обкатывают
Забыл: на аналоговых камерах система ВСЕГДА получается лучше. Если IP обязательно - смотри в сторону Axis. Кстати, у них в комплекте к камере идет халявная (на 4 камеры) версия Axis Camera Station (лучше с этими камерами ничего не работает, о какой бы поддержке не заявлял вендор) - докупи пару лицензий. Это работает даже на летном поле через Wi-Fi.
Интерфейс оператора НЕ ВЕБ (это я про ZM и Avr!).
1. Сохраняет на дисках видео как есть, без перепаковки (и изменения размера понятно - в планах может быть подключение камер с разрешением до 5МП)?
Какой битрейт выдают камеры? Подозреваю, что никаких дисков не хватит для хранения архива, например, за месяц.
1. Винты как раз не проблема 4x2Tb=SoftRAID5(3+1)=6Tb на пару недель непренывной записи для 6x2Mp камер вполне себе хватит, а больше и не нужно.
5. Пульта дистанционного управления (например IRLink).
p.s. Насчёт OSSirius DVR 301 было бы интересно отзывы услышать.
Весьма спорное утверждение, но спорить уже лениво. Далее, если бы был возможен оффтопик - был бы выбран TRASSIR.
Согласен, но у меня за 6 лет ни разу не получилось сделать IP лучше. IP это тоже ТЗ? Сэкономь на камерах, возьми регистратор подороже. Я рекомендовал бы ITV.
Таково пожелание заказчика. Ну и я тут с ним солидарен. Локально это попусту не нужно (почему и по каким параметрам универсальное веб решение проигрывает небольшому законченному нативному приложению я думаю объяснять не стоит?).
Какой битрейт выдают камеры? Подозреваю, что никаких дисков не хватит для хранения архива, например, за месяц.
Каждому по потребностям. :) А столько и не требуется. Неделя, максимум - две. Требовалось бы больше - был бы и другой подход (например внешний массив). Тут же довольно бюджетное решение может получится.
почему и по каким параметрам универсальное веб решение проигрывает небольшому законченному нативному приложению я думаю объяснять не стоит?
Всё-таки хочется это услышать =).
Согласен, но у меня за 6 лет ни разу не получилось сделать IP лучше. IP это тоже ТЗ? Сэкономь на камерах, возьми регистратор подороже. Я рекомендовал бы ITV.
Motion разве законченое решение? Я почему-то думал это инструмент для встраивания. ну в крайнем случае - по веб вещать, не?
sptim> Motion разве законченое решение?
Как регистратор — вполне. В sql базу пишет инфу о том когда и что регистрировал. По этим данным нативный клиент для просмотра нужного видео пишется в пол-пинка .
[quote]Всё-таки хочется это услышать =).[/quote]
Отвечать не успеваю - работу забросил. :) ОК. Давай посмотрим. Напоминаю, рассматриваем систему на линухе - отсюда и будем плясать. Хотя бы то, что сразу на первый взгляд можно сказать.
1. Де факто система автономна. Т.е. включил, ОС загрузилась, старовало ПО регистрации и клиент - отображает\записывет. По большому счёту это ядро линукса (может даже пересобранное без ненужных модулей) + минимально необходимая обвязка ибо нафиг ненужное? (ну и старт с флеш-диска вполне себе рабочий вариант)
1.1 С нативным софтом всё понятно. Ему дополнительно ничего не нужно - он как правило самодостаточный (или содержит необходимые компоненты).
1.2 Что же с веб клиентом? Какой-такой барузер? Так что получается вам еще и шелл графический подавай и софт соответствующий? Ого. а у меня тут голые иксы. (причем на этом минимуме уже способно нормально работать граф.JVM приложение, при установленном JRE конечно!)
2. Нагрузка на проц (про память не говорю - не так важно). Одно дело выполнять копеечный нативный код (ну или байткод для JVM) и совсем другой коленкор с js и web (а если тот же джава-аплет, то тем более нет смысла в вебе - пускай его локально в песочнице - меньше звеньев будет).
3. Отказоустойчивость. Кроме того, что меньше звеньев в нативном решении, так еще гарантируется нормальный отлов и обработка ошибок. Чего нельзя сказать про вебрешения.
4. Безопасность (должна быть безопасной). Как правило ВСЕГДА - чем меньше возможностей, тем безопаснее (т.е. если система урезана и удалены\заблокированы все возможные способы нештатных операций со стороны пользователя). А веб мало того, что тащит за собой кучу малу софта, так еще и не обеспечивает безопасности операций.
По этим данным нативный клиент для просмотра нужного видео пишется в пол-пинка
для реалтайм наблюдения у него встроенный мини-веб-сервер.
1. Для нативного веб приложения тебе все-равно понадобятся Х-ы, врядли кто будет тебе рисовать напрямую в фреймбуфер.
для реалтайм наблюдения у него встроенный мини-веб-сервер.
О чём я и упомянул.
1. Для нативного веб приложения тебе все-равно понадобятся Х-ы, врядли кто будет тебе рисовать напрямую в фреймбуфер.
Я может невнятно говорю? ;) Мои слова о нативности приложения ни в одном месте веб не подразумевали (я бы даже сказал - наоборот - противопоставляли). :)
Да. И какой отсюда вытекает вывод? Веб морда не нужна. О чём я и пытался сказать (может быть немного сумбурно, ну да я тут еще работать пытаюсь. :)).
p.s. Погляжу на выходных motion конечно, но хотелось бы конечно готовое решение.
Это в принципе основные изменения. Думаю при внимательном прочтении конфига вы
сами найдете нужные вам параметры, так как там все довольно хорошо
задокументировано.
Теперь вернемся к скриптам, которые отрабатывают при начале и окончании
события.
Так как нам надо писать видео с камеры, то для этого я использовал mencoder.
В папке /root/bin/ создаем скрипты recordstart.sh и recordstop.sh, которые
будут запускаться при наступлеии и окончании события соответсвенно.
Давайте заглянем внутрь recordstart.sh:
if [ "$1" -eq 218 ]
then
`/usr/bin/mencoder -ovc copy -oac pcm -delay 1.5 -mc 10 -o
/video/motion/$2/$FILENAME rtsp://192.168.95.218/mpeg4/media.amp > /dev/null`
elif [ "$1" -eq 219 ]
then
`/usr/bin/mencoder -ovc copy -oac pcm -delay 1.5 -mc 10 -o
/video/motion/$2/$FILENAME rtsp://192.168.95.219/mpeg4/media.amp > /dev/null`
else
`/usr/bin/mencoder -ovc copy -oac pcm -mc 10 -o /video/motion/$2/$FILENAME
rtsp://192.168.95.$1/mpeg4/media.amp > /dev/null`
fi
Скрипт принимает два параметра:
1 — имя камеры, хотя имя не совсем верно, так как это последний октет из IP
адреса камеры. То есть, как в нашем случае (мы используем 95 подсеть — 192.168.95.0/24). Таким образом, при передаче значения 211 — будет ясно, что
хотим обратиться к камере с IP 192.168.95.211
2 — директория, где будет храниться записанный файл. Сделано для того, чтобы
легче было искать. Опять же в нашем случае: имеется папка /video/motion в
которой хранятся записи, но для того, чтобы не мешать все в кучу, она содержит
поддиректории зон: kuhnya, balkon и т.д. Значит при передаче значения balcon — запись будеть производиться в директорию /video/motion/balkon.
Итак, при вызове скрипта в виде /root/bin/recordstart.sh 211 balkon — скрипт
будет писать с камеры с IP 192.168.95.211 в директорию /video/motion/balkon.
Надеюсь тут все более-неменее ясно :)
Небольшое пояснение: так уж оказалось, что у нас разные модели камер, которые
предоставляют разные способы доступа к потоку видео данных, из-за этого
пришлось ввести в скрипте проверки.
Теперь пройдемся по mencoder-у:
-ovc copy — означает, что видеоряд копируем, так как с камеры сразу идет в
mpeg4
-oac pcm — какой кодек использовать для звуковой дорожки, если камера позволяет
писать звук.
-mc 10 — Максимальная величина корректировки A-V синхронизации на один кадр (в
секундах)
-delay 1.5 — Задержка в мс, которая должна вноситься в каждый канал
Если у вас проблемы с синхронизацией видео и звукового ряда, тогда надо менять
значения для последних двух параметров — mc и delay.
Для теста можно использовать mplayer.
Ну вот, теперь при наступлении события, мы можем запускать данный скрипт.
Таким образом в конфиге для motion для нашей камеры прописываем в строке
on_event_start что-то похожее:
on_event_start "/root/bin/recordstart.sh 210 koridor1"
И он начнет писать :)))
Но ведь это все еще надо остановить :)))
Для этого используем второй скрипт /root/bin/recordstop.sh.
Скрипт принимает один параметр — все тот же последний октет из IP адреса
камеры.
Соответсвенно в строке on_event_end файла конфигурации прописываем что-то
вроде:
on_event_end "/root/bin/recordstop.sh 210"
Ну вот примерно и все, что касается конфигурации.
Теперь перейдем к рутинным операциям :)
У меня используются две, которые отрабатывают по крону.
1. Удаляет устаревшие файлы, которые страрше 21 дня.
2. Объединяет все файлы за день в один.
Рассмотрим скрипт для чистки. У меня он располагается в директории /root/sbin
и,
для того, чтобы враги не догадались, называется clean.sh
/bin/find /video/balkon -name "*.*" -mtime +21 -delete
/bin/find /video/motion/balkon -name "*.*" -mtime +21 -delete
В первой директории хранятся фотографии, сделанные motion — это параметр из
файла конфигурации в строке target_dir.
Вторая директория — куда пишется видео, запущенное из скрипта recordstart.sh
Это для объединения коротких роликов за день в один суммарный. (Для тех кто не
в курсе — он на питоне).
Единственное, что нужно менять — это переменная workDir — путь, куда mencoder
пишет свои файлы, все из того же recordstart.sh
Прописываем их в крон на выполнение раз в сутки, желательно ночью, пока карета
не превратится в тыкву :)
Запускаем motion следующим образом:
motion -c /path/to/config/file
где
/path/to/config/file — путь к нашему файлу с конфигом :)
А далее запускаем их при загрузке системы.
Ну вот наверное и все :)
Если будут вопросы — задавайте :)
UPD: будьте внимательны с скриптом на питоне, так как сбилась вся
табуляция, что для него очень критично.
Системы видеонаблюдения/видеофиксации сейчас очень популярны. И хотя на рынке их великое множество, желание сэкономить, особенно для использования дома или в секторе SOHO, часто приводит к мукам выбора.
В частности, у меня были следующие условия для домашнего NVR:
- работа серверной части NVR под управлением Linux в виртуальной машине VMWare ESXi;
- невысокая требовательность к ресурсам виртуальной машины при подключении 6-8 FullHD H.264 камер;
- возможность подключения и управления сервером NVR с Windows компьютера и смартфона (Android);
- невысокая стоимость (лучше бесплатно);
1. NVR с возможностью запуска серверной части в среде Linux
2. ZoneMinder
Первая система видеонаблюдения, которая проработала чуть больше года и явлалась первым опытом использования систем видеонаблюдения была ZoneMinder. Честно сказать, ZoneMinder достаточно сложен в установке и настройке, но даже не это стало основной проблемой в его использовании. Основная проблема появилась, когда я стал потихоньку заменять старые MJPEG камеры, на H.264-видеокамеры. Не знаю как сейчас, но версия с которой я работал несколько лет назад (1.28) не поддерживала H.264 потоки "из коробки", а то что получалось сделать подключив ffmpeg, хоть и работало, но достаточно сильно нагружало процессор, а качество детектирования движения оставляла желать лучшего. Попросту получалось либо записывать видео с камер почти непрерывно, либо при "загрублении" детектирования движения приходилсоь мириться с пропуском "важных" кадров. Кроме того, видимо из-за бешеной нагрузки на процессор, процессы ffmpeg, декодирующие H.264, падали и часто запись не велась вовсе. Пришлось искать что-то другое.
3. AVReg
В общем, переехал на AVReg. Установка AVReg уже проще, однако все равно далеко не тривиальна. AVReg работал в бесплатном режиме, поэтому из 6ти установленных камер запись производилась только с 4-х, однако запись видеоданных уже была стабильной. AVreg стабильнее, чем ZoneMinder, видеопотоки не "отваливаются". Однако сложность и нетривиальность настроек и "аляповатый" интерфейс немного раздражаал. Качество детектирования движения также оставляло желать лучшего. AVReg записывал очень много, поиск в архиве нужных событий неудобен. В конечном счете как мне сейчас кажется цена лицензии 1000 рублей за одну камеру для этого проекта сильно завышена. Адекватный ценник для AVReg рублей 400 за канал, не больше.
В общем, при работе с указанными выше проектами, было потрачено уйма времени и то, что в итоге получалось, не вызывало восторга. Время от времени, обращаясь к Гуглу за советом, что же еще хорошего имеется по теме NVR для Linux, пришел к выводу что небольшая плата за качественный софт для организации системы видеонаблюдения не такая уж плохая мысль.
4. Xeoma
Первое на что упал взор это была XEOMA.
Нужно сказать, что взор упал удачно, потому что, как оказалось указанный софт для NVR обладал всем тем, что мне и требовалось для организации домашнего видеонаблюдения:
- Система может работать в ОС Linux (так же как и в Windows, MacOS, Android, iOS и ARM)
- Серверная часть может быть запущена отдельно от клиентской части (фактически кроме бесплатной версии, которая имеет ограничения на подключению к серверу по сети) в голой консоли.
- Клиентский интерфейс может подключатся к серверу с любой ОС (Linux, Windows, MacOS, Android, iOS и ARM)
- Поддержка огромного числа видеокамер.
- Простая установка и настройка.
- Управление PTZ.
- Высококачественный детектор движения.
- Можно включить и использовать Web-интерфейс для доступа к системе.
- Большое количество и высокое качество модулей обработки видеопотока.
4.1. Установка XEOMA в виртуальную машину CentOS Linux
Как я уже писал одним из ключевых условий для использования NVR — это возможность ее запуске в виртуальной среде (VMWare ESXi 6.5 на машине i5-3570 @ 3.40Ghz/RAM 32Gb), причем конечно же очень желательно обеспечить минимизацию потребляемых ресурсов системой.
В связи с этим для начала была создана ВМ с CentOS 7.3, которой были выделены достаточно скромные ресурсы:
- CPU: 1 ядро
- RAM: 2Gb
- HDD1: 20 Gb (система)
- HDD2: 200 Gb (видеоархив)
4.2. Запуск консольного сервера видеонаблюдения Xeoma
Сервер XEOMA запускается не просто, а предельно просто. Честно сказать я был очень удивлен процессом установки и запуска системы в Linux, особенно после мытарств с ZoneMinder и AVReg.
Тут все просто:
4.3. Запуск клиентского приложения XEOMA
На рабочую станцию (работающей, к примеру, уже под Windows), также необходимо загрузить программный модуль XEOMA по указанной выше странице загрузки и запустить его командой:
Программа, запущенная в режиме клиента, сама обнаружит xeoma-сервер, подключится к нему (если он находится в той же подсети), предложит на выбор автоматическое сканирование сети или ручной ввод камер. Адрес сервера Xeoma также можно ввести вручную при помощи меню "Удаленный доступ" > "Подключение к удаленному серверу":
Здесь вводим IP-Адрес и пароль доступа, полученный ранее (см раздел 4.2.):
В итоге получаем приблизительно следующую картинку:
Собственно конфигурирование Xeoma такое же простое и интуитивно понятное как и установка этой системы. Полное руководство приведено на сайте производителя.
4.4. Потребление ресурсов виртуальной машины
Честно сказать, учитывая то, что Xeoma самостоятельно производит детектирование движения на основании которого производит запись видеопотока, у меня были сомнения в достаточности 1го ядра для виртуальной машины с запущенным Xeoma-сервером. Однако загрузка едиственного ядра при включенной детекции движения 6ти камерах составляла около 30-40% и оставалась в указанных пределах даже при активности на всех камерах. При отсутствии движения, загрузка опускалась ниже 20%:
Средняя HDD Latency при максимальной загрузке составляет 35-50ms, что достаточно много, однако такая задержка соответсвует одновременной записи видеопотока с 5-6 камер. Такая нагрузка случается нечасто, однако все таки стоит для записи видеопотоков выделить отдельный диск, подключив его как RDM-диск:
Выделенного объема дискового пространства в 200 Гб оказалось достаточно для хранения видеоданных от 6ти HD видеокамер в течении 2х недель:
4.5. Оптимизация настроек Xeoma
4.5.1. Детектор движения
В целом настройки детектирования и архива ведеоданных, предлагаемые Xeoma по умолчанию вполне нормально работают без каких либо изменений, однако учитывая ограничения ресурсов виртуальной машины с Xeoma-сервером, и отсутствие необходимости хранения излишней информации все-таки порекомендую сразу внести небольшие изменения в настройке модуля "детектор движения":
Изменяем порог чуствительности. Нужно немного понаблюдать за показаниями текущего уровня чуствительности при различных изменениях видеокадра и принять решение о минимальном пороге чуствительности. Меня устраивает значение 10, при котором детектор не пропускает никакого движения в камере. Значение же 5, установленное по умолчанию, фактически фиксирует "шум" видеокамер и незначительные изменения освещенности, приводя к большому объему записи в видеоархив.
Изменяем область детектирования. При помощи кисти и режима "стереть" удаляем лишние области, фиксация движения в которых нам не интересно.
Изменяем минимальный размер объекта. Точнее, немного увеличиваем. Размер объекта "по умолчанию", очень мал, что также приводит к ошибочному срабатыванию детектора и избыточной записи кадров, не содержащих ничего полезного.
4.5.2. Просмотр и архив
Настройки модуля "Просмотр и Архив" также возможно Вам стоит немного откорректировать. Мои настройки например выглядят так:
Предзапись. Я установил 5 секунд, что гарантирует, что за счет буферизации видеопотоков в видеоархив будет записана информация, не только с начала обнаружения движения, но и за пять секунд до него.
Время хранения этого архива. Учитывая что общий доступный объем дискового пространства, выделенного под видеоархив равен 200Гб, 2 недели — оказались оптимальной глубиной хранения.
4.5.3. Настройки декодирования
Для снижения нагрузки на сервер, при подключении к нему клиентов рекомендуется производить декодирование видеопотоков на клиентах. Для этого стоит установить настройки декодирования как показано на следующем рисунке:
4.6. Ограничения при использование виртуализации
На работу Xeoma в виртуальной среде, производителем установлены ограничения, которые могут быть для кого-то критичными. В частности в полной инструкции на систему написано следующее:
Для лицензий Xeoma (Xeoma Standard), Xeoma Pro, перехода с Xeoma Standard на Xeoma Pro и продлений добавлена возможность активации на любых виртуальных машинах. Для этого нужен постоянный доступ в Интернет на виртуальной машине. При пропадании Интернета лицензия может деактивироваться, но восстановится при возобновлении связи с Интернетом.
Работает это следующим образом: При пропадании Интернет, сервер Xeoma на виртуальной машине в течении 2х суток продолжает работать как ни в чем не бывало, записывает архивы, разрешает подключение клиентом, но все это работает до перезапуска сервера.
Если при перезапуске сервер не сможет обратиться через интернет за Активацией лицензии, то продуктивная работа сервера будет прекращена, т.е. данные с камер поступать не будут, архив прекратит записываться. При попытке запустить клиент, вы увидите следующее предупреждение:
Теперь пока у Вас не появится Интернет Xeomу вы сможете использовать только для просмотра архива. Для этого нажмите кнопку "Продолжить работу".
Однако, после возобновления доступа к Интернет, вас ждет одна неприятность (по крайней мере в последней версии 17.11.24). Несмотря на то, что с возобновлением доступа к Интернет функционал Xeoма заработает в полном объеме, при просмотре информации о Вашей активной лицензии (Меню > Информация > Активные лицензии) вы увидите следующее:
Ожидание в течении суток с небольшим, не исправило ситуацию, поэтому мне пришлось повторно ввести код активации лицензии вручную.
Учитывая не совсем понятную логику работы Xeoma, запущенной в виртуальной машине, я могу порекомедовать защитить себя от сброса настроек, которые вы сделали ранее, сохранив их одним из двух способов:
- С использованием меню в GUI клинета Xeoma: Меню > Установить > Восстановление > Сохранить настройки (или Экспортировать настройки).
- Сделать копию средствами Linux файла настроек /usr/local/Xeoma/settings.dat
Выводы
Xeoma очень хорошая система видеорегистрации. Своих денег она безусловно стоит. Это, как было указано выше, 875 рублей за 1 камеру при использовании стандартной лицензии. Для 6ти камер ее использование обойдется около 5000 рублей. Учитывая, то, сколько времени вы потратите на то, чтобы добиться приемлемой работы бесплатных решений — это безусловно невысокая цена.
Хочу отметить превосходную систему обнаружения движения, которая позволяет сохранять и быстро находить все без исключения значимые события, попадающие под ваши видеокамеры, без боязни что-то упустить. За счет этого, для двухнедельной записи с 6ти FullHD-камер достаточно выделить всего 200Гб дискового пространства, тогда как во многих недорогих регистраторах (например на базе CMS), для того, чтобы не пропустить события, приходится включать непрерывную запись, что для той же двухнедельной глубины архива потребует уже порядка 2Тб.
Ситуация изменилась с появлением китайских камер стандарта ONVIF 2.0 (Open Network Video Interface Forum). Теперь любую камеру отвечающую стандарту вы можете настроить с помощью ONVIF Device Manager.
Более того, вы сразу можете увидеть адреса и параметры потоков вещания с камеры. Да, да. Теперь потоков, как минимум — 2, не считая звука. Один архивный — в максимальном качестве, другой — рабочий в меньшем разрешении.
Веб-интерфейс камеры, программы CMS и интерфейс облака в браузере совершенно одинаковы, неудобны и требуют IE c ActiveX.
Благо, их можно с успехом заменить приложением XMeye установленным на Android или iOS. Но, прежде необходимо сделать нашу камеру видимой для облака. Для этого откройте порт по которому работает Onvif (8899) на вашем коммутаторе. В моём случае — это NAT Setting-Virtual Server. Если камер несколько, то внутренний порт для каждого IP оставляете прежним, а внешний меняете на пару значений. Далее, камера сама постучится в облако и предъявит свой индивидуальный CloudID. Вам нужно будет только добавить его в свой профиль в облаке.
Собственно, сама по себе камера уже может детектить движение, стримить видео и отправлять аллармы. Вкупе с облачным сервисом XMeye — это готовый сервис мониторинга.
Если вам хочется иметь свой собственный регистратор с архивами, и вы любите Windows, то ставьте бесплатные iSpy, или SecurOS Lite (до 32 камер) или бесплатную-же версию (до 8 камер) Xeoma. Кстати, у последней есть версии для Mac OS X, Linux включая ARM и Android.
С настройками не должно возникнуть проблем, так что можете дальше не читать. Остальная часть статьи написана для Linux.
Я был приятно удивлен обнаружив в Zoneminder v.1.30.0 визард для настройки ONVIF камер. Он позволяет подключить к консоли любой из потоков идущих с камеры в зависимости от аппаратных возможностей и потребностей оператора.
1. Определите адреса потоков через ONVIF Device Manager или Xeoma. У вас должно получиться что-то похожее:
Не забудьте заменить звездочки (*) своими данными.
2. Проверьте адреса в проигрывателе VLC. Меню-Медиа-Открыть IRL
3. Добавьте новый монитор с параметрами:
Source Type — Remote
Remote Host Path — rtsp://192.168.1.1*/user=****_password=****_channel=1_stream=1.sdp?real_stream
Есть желание собрать фронтальный видеорегистратор для авто на основе платы Raspberry PI 2 (Model B) и какой-нибудь вебки с питанием от USB.
Возникает сразу пачка вопросов:
- Стоит ли смотреть на широкоугольные (>100° угла поля зрения) камеры или же проще будет взять любую, запилив туда нормальную линзу (в фототехнике вообще не секу, возможно ли увеличить поле зрения, заюзав внешнюю линзу, без смены объектива оригинального устройства?)
- Есть ли какие-то неочевидные проблемы с драйверами для вебок на ARM-овских образах линухи?
и какой-нибудь вебки с питанием от USB
Нет смысла, матрицы вебок слабоваты.
Можете дать совет из чего лучше тогда компоновать камеру и на какие характеристики смотреть при выборе?
Там больше проблем от вибраций будет чем от матрицы.
Вебки разные бывают, бывают и с хорошими матрицами.
Смотри на поддержку камеры без использования проприетарщины и на корпус.
Хотя если эйчдями не париться и пилить и смазывать лень — бери любую подходящую и когда сдохнет просто выбрось и новую воткни — не такие они и дорогие эти камеры.
Остаётся тогда вопрос по углу обзора.
На этих ваших хреняндекс маркетах всего 12 моделей разной степени неадеквата имеют угол поля зрения >110°.
Мне прямая дорога на алиэкспресс или поле зрения можно как-то пропатчить руками, паяльником и стеклом?
Купил недавно, а потом вернул, вебку от A4tech, fullhd, 30fps.
Потому что максимум что выдавало - HD с 20 fps, с фуллхд было от силы 8 кадров. Так что, если у вас нет способа протестировать кучу вебок, чтобы найти нормальную, то дерзайте.
А почему не купить готовое устройство (КМК будет дешевле)?
- Есть ли какие-то неочевидные проблемы с драйверами для вебок на ARM-овских образах линухи?
У меня какой-то logitec, взлетело без проблем, но на B+ при работе с камерой ресурсы жрутся огого как.
Китайский видеорегистратор (при том с честным 30fps FullHD, а не 15-20fps как выдают в реальности многие вебки и мучениями с кодированием видео на слабой малинке) будет в несколько раз дешевле.
А почему не купить готовое устройство (КМК будет дешевле)?
30-баксовый noname из Китая подох на прошлой неделе и прихватил с собой SD карту. Каждая подобная покупка обходится в 2 месяца ожидания без надежды на успех. Проще один раз заморочиться и собрать самому, зная как оно работает. В крайнем случае можно будет перепрофилировать материнку под другие задачи.
Пока остановился на варианте PI 2 Model B + PI Cam Module + Wireless Adapter. Если не натыкаю вменяемую вебку с углом в ~120°, придётся ограничиться материнкой и камерой-расширением к плате.
Конечно можно и нужно, особенно если форма рук позволяет.
Это же банальная оптика, никаких секретов.
Особенно если она без автофокуса.
У вебок два режима работы: на качество и на кадры в секунду.
Если выбран режим на качество — кадров будет меньше при меньшем освещении.
Если на кадры, то качество будет страдать, но зато кадры проседать не будут.
По собственному опыту могу посоветовать Defender G-lens 2577 из недорогих качественных камер, доступных в расейской рознице.
За такую цену лучше фиг найдёшь, при тусклом офисном освещении она даёт честные 60фпс в разрешении 800×480 или 30фпс в 1280×720.
Оптика узкая, да.
Практика показывает что вебка+ежевика получается дешевле аналогичного по качеству готового устройства.
Ссылку на честный регистратор в студию.
возможно ли увеличить поле зрения, заюзав внешнюю линзу, без смены объектива оригинального устройства?
На коленке невозможно.
Подробнее, пожалуйста. Что именно нужно, какие материалы, какой навык.
Зато к Raspberry PI можно, скажем, примотать экран и вторую вебку на зад для парковки, её же использовать как мультимедиа-проигрыватель, воткнуть датчики температуры и ещё много интересных вещей, которые пожадничал производитель автомобиля :3
Проблема с тряской решается подвесом камеры сверху за пружину средней жёсткости, чтобы чуть проминалась под собственным весом.
Поле в пространстве предметов ограничено передней частью корпуса камеры, такое коническое углубление спереди. Это бленда, фактически.
Предположим ты и с этим справишься. Но на коленке ты не сможешь отцентрировать даже двухкомпонентную систему и искажения будут присутствовать даже в центре изображения.
Если в линуксе под другими архитектурами работает, то и на ARM заведется. Другая проблема — ассемблерные вставки. Мне, например, одну свою библиотечку пришлось малость подрихтовать. Зато теперь ассемблерные вставки в ней и на i386, и на AMD64, и на ARM работают.
Но вот другой вопрос: потянет ли "малинка" видео в HD1080? А еще лучше в 4 раза больше, т.к. на HD1080 разглядеть номера едущей впереди на расстоянии сотни метров машины почти невозможно.
Вот взять бы помощней систему, можно было бы в реальном времени распознавать номера автомобилей в поле зрения и в лог сваливать. Удобно, однако.
Это показометр, а не регистратор! Нужно не меньше HD1080. А еще лучше — QSXGA 2560x2048. Тогда уже можно назвать регистратором.
А как ты собираешься реализовать аварийную блокировку памяти при сотрясении?
Тогда проще GoPro купить.
Там сразу и широкий обзор и мегапиксели и всё в одной коробке и на вибрации ей посрать.
Goury ★★★★★ ( 10.05.15 10:59:43 )
Последнее исправление: Goury 10.05.15 11:00:42 (всего исправлений: 2)
у китайцев есть широкоугольные объекивы к камерам (на китайские вебки подходят).
Meanwhile in Belarus.
Регик собран, сегодня проехался немного по городу.
Это на малинке с ее родным камерным модулем? Если так, то сколько кушает проца и какая малинка, какой софт? Я хочу компактный регик на работу сварганить.
Это на малинке с ее родным камерным модулем? Если так, то сколько кушает проца и какая малинка, какой софт? Я хочу компактный регик на работу сварганить.
Да, это малина с камерой от тех же ребят. По потреблению ресурсов и самому софту скажу после выходных, сейчас вдалеке от цивилизации.
Спасибо, буду ждать!
Добрался до цивилизации, сейчас буду медленно спамить.
У меня в Минске с электроникой подобного рода довольно тухло, как и с вообще доставкой напрямую в Беларусь, поэтому брал с рук - последняя малинка (RPI 2+) обошлась в $55, камера $26. Насколько реально взять дешевле в других городах\странах - смотрите сами.
По операционке: предпочитаю арч, поэтому был впёрт он. Хард (флешка) разбит на 2 партишена: немного для оси, остальное в FAT32 для видео.
По софту: производитель камеры наклепал примеров юзания своего поделия на обычном баше с параметрами, а не на вызовах API из C\C++, поэтому задача кода - собрать параметры в командную строку. На чём делать - до фонаря, я слепил за 20 минут на пыхе.
Читайте также: