Какие есть бюджетные ip видеосерверы для оцифровки аналогового сигнала в цифровой?

Question

[Константин]

Здравствуйте.
Подскажите пожалуйста, какие есть бюджетные ip видеосерверы для преобразования аналогового сигнала в цифровой.
На входе 4-8 входов BNC с аналоговых камер, на выходе RJ45 для подключения к роутеру или сразу к одноплатнику.

Answer 1

[rPman]

Систем видеонаблюдения?

Я сильно не копался, но цены на этом рынке какие то нездоровые,...

Настоятельно рекомендую найти способ уйти от аналогового сигнала и перевести инфраструктуру на готовые цифровые камеры.

Существуют решения (коннекторы bnc - ethernet) относительно дешевые (парами 2-3 т.р.) которые позволяют по имеющимся уже протянутым аналоговым линиям передавать ethernet. Просто нужно помнить что bnc это каоксиальная линия, и при необходимости, если найти сетевые карты, то можно строить сети не точка-точка топологии (т.е. когда к одному кабелю простым соединением подключяются сразу несколько устройств, деля 10мбит канал) я лично не проверял, вполне возможно что доступные коннекторы про эту фишку тупо забыли, ибо так можно продавать в два раза больше коннекторов.

Стоимость самодельного сервера по работе с ip-камерами на порядок дешевле стоимости централизованных энкодеров. Подбор камер - отдельный разговор, ключевое слово чтобы они могли отдавать сырой видеопоток без проприетарного приложения (дешевые потребительские камеры этим грешат, завязывая решение на платный видеосервис от производителя).

Comments

[Константин]

Спасибо, но цель - уйти от проприетарной обработки видеосигнала. От камеры до записи видеофайла на диске не должно быть проприетарного ПО вообще.

[rPman]

Константин, тогда у тебя точно нет других вариантов кроме готовых ip камер с поддержкой rtsp

и быть готовым что кодек у потока будет mjpeg, так как если на сервере понадобится обработка видео, открытых не проприетарных кодеков пережимающих на лету не найти (у nvidia есть но он проприетарный)

Answer 2

[mordo445]

"Бюджетные видеосерверы" это только про китайский видеорегистратор с аналоговыми входами. Он умеет отдать потоки по RTSP если не слишком старый, и стоит 50..100$ (кто просит больше -- мошенник). Но там софт на линукс на борту, с вполне недооткрытым проприетарным ПО, и по техзаданию не проходит. Да и зачем там RTSP и писать на разбухе если регистратор готовый? Но раз надо, значит надо. Вариант джва -- плата видеозахвата. Изделие вымирающее, и если больше 1 канала, то USB не будет (или будет крайне не бюджетное под 3.1 и не для ваших целей), 4 канала уже PCI, больше PCI-E. Пахнет IBM Compatible и цены кусаются, так как спрос низкий. Да к тому же драйвер тоже писал производитель и о совместимости и открытости не заботился. Третий вариант не дешев и проприетарен -- использовать видеоенкодеры, например от axis. Не будем его рассматривать.
Эти варианты выглядят удручающе. Но есть вариант, который возможно устроит вас, и даже всесторонне заинтересует, если вы разработчик и не просто так интересуетесь безпроприетарностью. Вы можете взять китайский аналоговый регистратор и перепилить его ПО под свои нужды, немного изучив используемую платформу и ее возможности. Люди которые по фану или профессионально этим занимаются есть, найдите например iTuneDVR на форуме dahuacctv или hikvision.msk

Comments

[Константин]

остановился на варианте покупки ip камер с отдачей потока в сжатом виде h.264/h.265, например камеры на базе процессора Hi3516Ev300.

Вместо видеорегистратора взять одноплатник, процессор которого на аппаратном уровне поддерживает кодирование и декодирование h.264/h.265, Например Rock Pi 4.
Сколько потоков 1080p он возьмёт ещё закадка. На 7 камер думаю хватит.

[mordo445]

Ну, с одноплатником два стула - один зонмайндер, другой что то любительское или свое применить на ffmpeg, vlc или еще чём. Записывать 7 камер - точно хватит, показывать в полном разрешении, не должно хватить, софт должен поддерживать аппаратное декодирование платформы, что бы хватало. Но без проблем можно просматривать 7 дополнительных потоков, с этим справляется 3 пай.

[Константин]

mordo445, да, сегодня выяснил, что ПО, которое поддерживает декодирование на аппаратном уровне я не найду, решил прийти к чуть другому варианту.
Автор NVR https://github.com/scottlamb/moonfire-nvr пишет, что без декодирования, если писать поток в файл, то 6 потоков 1080p/30fps займёт меньше 10% CPU на Raspberry Pi 2.
Т.к. запись ведётся кусками, например по 60 минут, 30 минут, то можно просто по крону и своему написанному скрипту проходить по очереди все эти файлы на моих 7 камерах и вычленять детекцию движения через тот же motion.
Ещё не пробовал, но предположительно оставшихся 90% CPU (от 4х1500Mhz на odroid c1) должно хватить на декодирование 1 потока 1080p/15fps.
Просто будет задержка данных по детекции движения на N минут. (30-60мин например).

[mordo445]

Все NVR пишут по одному алгоритму -- поток в архив как есть, одновременно через алгоритм детекции движения, к потоку добавляются метаданные о том что движение было, через 10-15 секунд видеопоток (уже в контейнере) удаляется, если нет метаданных о наличии движения. Так можно сделать предзапись и постзапись, до и после события. Вам тоже советую постзапись в свой алгоритм ввести, сам же я предпочитаю применять hevc, h.265 с непрерывной записью - слишком много ценных событий было потеряно из за экономии на жестких дисках. Мы с операми ловили мошенников по отражению в витрине, такое алгоритмы движения не секут например. А мунфайр я не пробовал, посмотрю что оно такое, спасибо

[Константин]

mordo445,

одновременно через алгоритм детекции движения

чтобы найти на видео движение, нужно сначала декодировать сжатый поток h264/265. На это уходит много ресурсов. Во всех (я так думаю) видеорегистраторах поддержка кодирования/декодирования h264/265 встроена в процессор (SoC), поэтому один одноплатник может декодировать сразу по 8/16/32 потока.
Одноплатник как raspbery pi, не имеет аппаратной поддержки h264/265, поэтому если она 2 потока осилит, это уже хорошо наверно (не пробовал ещё).
Остаётся только писать без декодирования мои 7 сжатых потоков в файл без детекции движения.
И уже после сохранения куска файла в 15/30/60мин. по очереди эти файлы перебирать на детекцию движения.

[mordo445]

не всё так однозначно, потому что:
1. движение можно искать в дополнительном потоке.
2. движение ищет камера и присоединяет к метаданным потока или пересылает в отдельных пакетах данных, соответствующих протоколу обмена.
В основном потоке ищут только жирные большие программы заточенные под жирные большие серверы, и под использование в аналитике дальше конечно. SoC NVR обычно это 2-4 ядра A7, нет в малоканальных нвр ни аппаратной поддержки, ни отдельных микросхем декодеров. Это не выгодно. Все делают 1 и 2, никто не перебирает файлы, так как тут вы умножаете нагрузку на диски в двое, и пропускную их способность, кстати, тоже съедаете. Посмотрите протокол ONVIF, там можно получить метаданные о движении или проприетарные протоколы двух главных китацев - дахуа с хиквижном. У дахуа оно вообще пытается в rest-совместимость, с ним проще что то написать свое.

Answer 3

[Norco-77]

регистратор нужен? немного непонятна конечная цель..

Comments

[Константин]

в роли регистратора будет одноплатник на линуксе.
Конечная цель - на одноплатнике на линуксе брать сигнал по ip и писать на внешний жёсткий диск, подключённый по usb.

Или более точно, конечная цель - видеонаблюдение с 6 камер + уйти от проприетарной обработки видеосигнала. От камеры до записи видеофайла на диске не должно быть проприетарного ПО вообще.

Answer 4

[Newbie2]

Видеорегистратор, не?

Comments

[Константин]

в роли регистратора будет одноплатник на линуксе

[Newbie2]

Константин, бывают четырехканальные usb-видеорегистраторы, но как там с дровами на линукс я не знаю.