[_Watcher_ 0]

Здравствуйте,

Требуется разработка опытного образца 8 канального аудио видео регистратора, удовлетворяющего следующим требованиям:

- Регистратор должен иметь возможность установки в 19 дюймовую стойку.

- Высота - не более 2U. Регистратор должен обеспечивать:

- прием и запись сигналов от 8 источников аудио сигнала и 8 источников видеосигнала;

- питание каждого микрофона 5В, ток не более 10 мА;

- входное сопротивление линейного входа источника аудио сигнала -600±200 Ом;

- питание по выделенным линиям видеокамер напряжением 5 В, ток потребления одной камеры - не более 100 мА;

- входное сопротивление по входу видеосигнала - 75 Ом;

- чувствительность по входу видеосигнала — 1 В.

- Регистратор должен предоставлять возможность автономной записи на съемный встроенный носитель аналоговых аудио и видеосигналов, также выполнять- - регистрацию метаинформации (дата время, имя канала, важность).

- Регистратор должен поддерживать режим сохранения метаинформации в файлах.

- Регистратор должен предоставлять возможность задания шаблона для генерации имени файла записываемых данных.

- Аудиоканалы регистратора должны обеспечивать запись звуковых данных с микрофона со следующими характеристиками:

- частота дискретизации звука: 8000 Гц, 11025 Гц, 16000 Гц, 22050 Гц;

- формат: ИКМ16, A-Law, U-Law;

- формат файлов: WAV, WSD;

- соотношение сигнал / шум: не хуже 80дБ;

- уровень нелинейных искажений — не более 1% в диапазоне от 300 до 7500 Гц (неравномерность АЧХ канала регистрации - не более 3 дБ).

- Видеоканалы регистратора должны обеспечивать запись видео данных с характеристиками не хуже чем:

- кадровая частота: регулируемая от 1 до 25 кадров/сек.;

- кодек: MJPEG, Н.264;

- размер кадра: до 720x576 включительно.

- Регистратор должен поддерживать следующие режимы старта записи:

- по команде от пользователя;

- по акустопуску;

- по детектору движения;

- по расписанию;

- по команде от программного интерфейса.

- Регистратор должен поддерживать режим циклической записи по каналам в случае завершения свободного места на внутреннем носителе.

- Регистратор должен обеспечивать возможность настройки параметров записи аудио и видео независимо по каждому каналу записи.

- Регистратор должен предоставлять возможность управления своей конфигурацией посредством программного интерфейсам также с помощью интерфейса администратора или web-интерфейса.

-Регистратор должен поддерживать режим авторизации, как для пользователя, так и для программного интерфейса.

-Регистратор должен предоставлять доступ к записанным данным посредством программного интерфейса, а также с помощью интерфейса администратора или web-интерфейса.

-Регистратор должен предоставлять доступ к данным каналов мониторинга посредством программного интерфейса, а также с помощью интерфейса администратора или web-интерфейса.

-Регистратор должен предоставлять возможность удаленного управления громкостью аудио каналов и яркостью, контрастностью видеоканалов.

-Регистратор должен предоставлять возможность одновременного мониторинга всех его каналов (аудио и видео) посредством программного интерфейса.

-Регистратор должен вести журнал всех действий пользователя и действий, выполненных с помощью программного интерфейса.

-Регистратор должен иметь съемный встроенный носитель размером достаточным для хранения не менее 2-х суток информации по всем каналам (при работе в режиме максимального качества преобразования).

-Регистратор должен сохранять работоспособность при смене встроенного носителя.

-Регистратор должен иметь Ethernet адаптер пропускной способностью 100/1000 Мбит/с.

-Регистратор должен поддерживать динамический и фиксированный режим получения IP адреса.

-Регистратор должен поддерживать функцию экспорта записанных данных.

-Регистратор должен поддерживать режим вставки водяных знаков в видеопоток(маскирование).

-Регистратор должен иметь функцию диагностики состояния линии микрофонов и видеокамер (вкл/выкл/исправно/неисправно).

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

-Регистратор должен иметь функцию удаленной перезагрузки функцию удаленного перезапуска каждого аудио и видеоканалов.

 

Можно использовать за основу любой готовый поддерживаемый и продаваемый регистратор. Цену и сроки обговариваются с возможным исполнителем.

 

[Demeny 0]

Могу предложить изготовить опытный образец на основе 8/16-канальной платы видеозахвата с интерфейсом PCI собственной разработки (на базе FPGA), то есть взять готовый корпус 2U, пром. материнскую плату под него, и переконструировать (а на первом этапе - воткнуть как есть) PCI-плату видеозахвата. Если интересно - пишите в почту demeny [at] yandex.ru

[_Watcher_ 0]

 

 

Могу предложить изготовить опытный образец на основе 8/16-канальной платы видеозахвата с интерфейсом PCI собственной разработки (на базе FPGA), то есть взять готовый корпус 2U, пром. материнскую плату под него, и переконструировать (а на первом этапе - воткнуть как есть) PCI-плату видеозахвата. Если интересно - пишите в почту demeny [at] yandex.ru

 

Все-таки желательно, чтобы это было отдельное устройство, а не компьютер с набором плат.

[_3m 4]

_Watcher_ в вашем задании нечетко описаны требования к видеовходам.

Можно предполагать что входы cvbs.

Еще не указан формат сигнала secam/pal/ntsc, должен ли регистратор переваривать смену формата "на ходу" (была камера пал, ее выдернули и в тот же вход воткнули ntsc)

Также вы не упомянули о функции деинтерлейса. 8 каналов адаптивного деинтерлейса - это существенно.

 

[Demeny 0]

Все-таки желательно, чтобы это было отдельное устройство, а не компьютер с набором плат.

Интерфейсная плата будет одна, и на ней реализовано 8 видео(+аудио)входов + FPGA, к материнской плате она будет подключена по шине PCI (или PCI Express), и в её задачу будет входить только "слив" аудио/видео потоков с нужной производительностью в память компьютера посредством PCI Master.

Ну, ещё триггер записи, наложение "водяных знаков" (если нужно) и отслеживание исправности каналов.

Всё остальное (кодирование MJPEG/H.264, сеть, файловые операции, предпросмотр и т. п.) удобно делать на мощном процессоре с быстрой памятью и надёжной дисковой подсистемой, под операционной системой (не обязательно Windows).

==

А что имеется в виду под "отдельным устройством"? FPGA? Набор аппаратных кодеков? Всё равно нужна дисковая подсистема с объёмными носителями (а это SATA), приличный объём RAM, быстрая сеть и т. п.

Зачем изобретать велосипед, который к тому же окажется золотым?

[DSP_ACE 0]

Оцениваю вашу работу по разработке видеорега в 18к$ 3-5 месяцев

 

Производство печ плат в Китае по нашим каналам

Дополнительно могу отдельно предложить сборку сигнальной партии в Москве 20 шт

У нас автомат Juki-740 Сборка первого экземпляра пауза на отладку потом остальные 19

 

Также можем организовать производства партии видеорегов в Китае (Шеньжень)

 

Из элементной базы два главных претендента

1 Texas Instruments DM388(DM38x) - очень продвинутый чип , аппаратная фильтрация видеошума, распознавание лиц из 32

шаблонов и тд Поддерживает цифровой интерфейc камеры MIPI

https://developer.ridgerun.com/wiki/index.p...2_Video_Capture

Но дорогой

 

2 HiSilicon Hi3516D

Дешевый китайский 11$

 

 

Пишите

[email protected]

пришлю фото наших видеорегов и подробности

[DSP_ACE 0]

Есть любопытное готовое предложение

 

На фото в предыдущем письме изображен одноканальный видеорег на TI dm355(65,68)

Его размеры 38х175м Есть выход на езернет , usb, внутренний nand-flash до 16 гигобайт

Возможности проца ( h264 , mjpeg etc) превышают ваши требования Цена dm365 12$/1к шт что очень неплохо

Софт по интеграции модулей в систему через ethernet или через usb-hub звездой может быть написан очень быстро

 

Т о можно собирать модульный видеорег , например в 19" 1U рэке :

 

1)при вертикальном расположении модулей

с шагом 10мм можно установить 40 модулей и т е макс 40 каналов

 

2)Если требования по тряске то горизонтальное расположение модулей, при ширине модуля 38 мм = 10 модулей

на одной интегральной плате х 2 платы по высоте= 20 каналов

 

В первом варианте преимущество сборки под конкретное число каналов чтобы не переплачивать

 

Разработка готова и оттестирована , все насквозь просматривается через JTAG в Code Composer,

установлен Uboot и UImage (Linux)

 

Видимо необходимы небольшие крепежные коррекции а также для расширения обьема встроенной флэш

памяти ( 16 GByte Nand) нужна розетка для подключения внешней usb флэшки ( сейчас стандартный микро-usb)

 

Стадия готовности - несколько дней

Цена разработки 15 к$ Столько она стоила американскому заказчику для которого мы ее делали

Но мы имеем право продавать ее как свою разработку тоже

 

Возможны промежуточные варианты

Например изготовление нами тестовой партии по минимуму цены для проверки вами

Далее выкуп вами лицензии на производство с передачей всей документации или дальнейшие закупки вами

Весь риск как вы понимает в этом случае на нас

 

 

 

 

 

 

[DSP_ACE 0]

Интерфейсная плата будет одна, и на ней реализовано 8 видео(+аудио)входов + FPGA, к материнской плате она будет подключена по шине PCI (или PCI Express), и в её задачу будет входить только "слив" аудио/видео потоков с нужной производительностью в память компьютера посредством PCI Master.

Ну, ещё триггер записи, наложение "водяных знаков" (если нужно) и отслеживание исправности каналов.

Всё остальное (кодирование MJPEG/H.264, сеть, файловые операции, предпросмотр и т. п.) удобно делать на мощном процессоре с быстрой памятью и надёжной дисковой подсистемой, под операционной системой (не обязательно Windows).

==

А что имеется в виду под "отдельным устройством"? FPGA? Набор аппаратных кодеков? Всё равно нужна дисковая подсистема с объёмными носителями (а это SATA), приличный объём RAM, быстрая сеть и т. п.

Зачем изобретать велосипед, который к тому же окажется золотым?

Всё остальное (кодирование MJPEG/H.264, сеть, файловые операции, предпросмотр и т. п.) удобно делать на мощном процессоре с быстрой памятью и надёжной дисковой подсистемой, под операционной системой (не обязательно Windows).

 

Единственная причина по которой удобно( вернее необходимо) делать видеообработку одним процессором это сильносвязанность алгоритма обработки по всем N-измерениям (изображениям) и при этом в реальном времени

Например когда военный робот(самолет. танк) по двум камерам(аналог человеческого зрения) должен определить удаление обьекта по нечеткому изображению

А это корреляционный или спектральный анализ по двум измерениям

Там миллисекунды решают все - нельзя тратить время на пересылку кадра

А если время уменьшить сжатием (напр h264) то пропадут мелкие детали в которых вся соль в бою

 

Поэтому несжатое видео по N каналом без малейшей задержки молотит один мощный проц(или n ядер на кристалле) Но конечно это должен быть не Интел с

его длинющими командами без аппаратных присадок А про вентилятор или водяной радиатор для встраиваемых систем даже смешно слышать

 

Для этого Texas разработал свой последний ( судя по тому что он лет 5 не обновлялся ) шедевр - омар5

Там на кристалле 4 ввода с СSI камер ( круговой обзор для самолета танка или авто) пара ядер арм и видео dsp и множество аппаратных приблуд

 

В здешнем же проекте к счастью требования довольно примитивные и нет проблем с последствиями вышесказанного - охлаждением и пропускной способностью шин памяти

и дисковой подсистемы изза n-канальности в одной точке

Каналы можно благополучно разнести каждый на свой дешевый процессор и память Причем в сеть пихать сжатый видео сигнал для оперативного просмотра а на флэш писать несжатый

По цене получается дешевле чем однокристальная суперсистема

 

[Demeny 0]

Каналы можно благополучно разнести каждый на свой дешевый процессор и память Причем в сеть пихать сжатый видео сигнал для оперативного просмотра а на флэш писать несжатый

По цене получается дешевле чем однокристальная суперсистема

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

Да и как обеспечить дисковую подсистему SATA, все процессоры "полезут" писать на диск одновременно, нужно будет разруливать и строить быстрый и внятный арбитраж (с приоритетами, или без). Ваших 16 Гбайт NAND надолго не хватит, особенно если писать на них несжатое видео, как Вы предлагаете. А заменять "на ходу" их как? (см. требования ТС).

[DSP_ACE 0]

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

Да и как обеспечить дисковую подсистему SATA, все процессоры "полезут" писать на диск одновременно, нужно будет разруливать и строить быстрый и внятный арбитраж (с приоритетами, или без). Ваших 16 Гбайт NAND надолго не хватит, особенно если писать на них несжатое видео,

как Вы предлагаете. А заменять "на ходу" их как? (см. требования ТС).

 

что значит полезут одновременно ? Система должны быть построена по принципу TDM - time domain multiplexing Каждому каналу свой временной слот на уровне кадра

 

sata в dm36x нет Это в dm38х и старших моделях davinci Вместо этого я бы предложил присоединять usb флэш или usb диск на каждый канал Разьем есть Usb провод позволит располоагать накопитель

в удобном для смены месте Цены на магнитные usb драйвы не сильно отличаются от sata-шных Ну за удовольствие писать на твердотельный драйв придется заплатить

 

Я вижу архитектур как раз в том что для архивации на накопитель ( при желании) пишется несжатый поток с максимальными деталями А реал-тайм в сеть сжатый для реал-тайм реагирования и web- просмотра

Для просмотра в многооконном режиме сжатые в 10-20 раз восемь h264 потоков через ethernet попадают на пульт просмотра Причем тут выполняется естественное соотношение - чем больше

каналов на дисплее тем меньше точек на канал соотв может быть сильнее сжатие То есть общий поток в видео пульт величина постоянная

 

В вашем варианте (как и в варианте с одиночным видео сурперпроцессором) 8 несжатых канала видео просто не пролезут в один sata драйв - придется все равно параллелить и тд или сжимать

 

А в моем варианте если писать сжатые собирая их из 8 канальных модулей через Ethernet or usb в 1 sata накопитель то вобще все просто - один мощный проц с огромным вентилятором и материнкой за 100-200 баксов

заменяется 8 процами за 12 баксов без вентиляторов

 

А вы вообще пробовали закодировать и передать в сеть 8 h264 потоков с вашей платой на компе с вменяемой ценой? (ну хотябы на QNX - Windows и Linux отметаем )

[Demeny 0]

что значит полезут одновременно ? Система должны быть построена по принципу TDM - time domain multiplexing Каждому каналу свой временной слот на уровне кадра

Ещё раз. Как 8 разных процессоров будут писать свои разные файлы на едином физическом носителе? Если по очереди - то основное время сожрёт перевод головок от файла к файлу. Ну или буферизация должна быть весьма некислой у каждого (!) процессора. И не отменяет разработки диспетчера (к вопросу о нескольких днях разработки).

sata в dm36x нет Это в dm38х и старших моделях davinci Вместо этого я бы предложил присоединять usb флэш или usb диск на каждый канал Разьем есть Usb провод позволит располоагать накопитель

в удобном для смены месте Цены на магнитные usb драйвы не сильно отличаются от sata-шных Ну за удовольствие писать на твердотельный драйв придется заплатить

USB-флэшку на каждый канал??? :( Ещё и на выносном проводе? И всё это в 19' стойке? И ещё доплатить за удовольствие писать на твердотельный драйв? Человек стремится к надёжности в каждой строчке задачи, а Вы ему USB-флэшки предлагаете перетыкать.

В вашем варианте (как и в варианте с одиночным видео сурперпроцессором) 8 несжатых канала видео просто не пролезут в один sata драйв - придется все равно параллелить и тд или сжимать

Я и не предлагал писать несжатое видео на SATA драйв, это безумие и незачем для видеорегистратора. Несжатое видео забирается с декодеров платой посредством FPGA в локальную память, в соответствии с выбранными каналами, числом кадров в секунду и прочими настройками. Отдельно организуется общий поток из локальной памяти в память PC, где уже подключается нужный кодер, предпросмотр, сохранение на диск, сеть и т. д.

Можно, кстати, рассмотреть вариант аппаратного кодера прямо на интерфейсной плате, и в PC гнать уже закодированный поток. Но это сильно усложнит периферийную плату ввиду необходимости распараллеливания процесса упаковки видео, с соответствующим увеличением локальной памяти и программного обслуживания всего этого дела, которое можно делать на PC.

А в моем варианте если писать сжатые собирая их из 8 канальных модулей через Ethernet or usb в 1 sata накопитель то вобще все просто - один мощный проц с огромным вентилятором и материнкой за 100-200 баксов

заменяется 8 процами за 12 баксов без вентиляторов

А собирать по "Ethernet or USB" и писать на SATA кто будет? Неужели не материнская плата с процессором Intel?

А вы вообще пробовали закодировать и передать в сеть 8 h264 потоков с вашей платой на компе с вменяемой ценой? (ну хотябы на QNX - Windows и Linux отметаем )

Про передать в сеть задачи не было (как нет её и здесь, это всё же не транслятор цифрового вещания TV, а видеорегистратор), а так да, под Windows в качестве основы для видеорегистратора (с функцией видеоквадратора) на 8/16 каналов аналогового PAL/NTSC видео работает.

[DSP_ACE 0]

>Ещё раз. Как 8 разных процессоров будут писать свои разные файлы на едином физическом носителе? Если по очереди - то основное время сожрёт перевод головок от файла к файлу. Ну или буферизация должна быть весьма некислой у каждого (!) процессора. И не отменяет разработки диспетчера (к вопросу о нескольких днях разработки).

В моем случае через сеть удобнее всего передавать картинку для видеоквадратора - то есть все 8 видеопотков в сумме должны

иметь скажем 1920х1260х60гц что вполне реально без всякого сжатия на любом компе в местной сети и побочно позволяют наблюдать с другого конца планеты по инету ну может со сжатием

 

В свете сильного падения цены на бит информации в флэшах ( за 6 лет на порядок ) связываться с sata вообще нецелесообразно

Реальный флэш чип 48 ног tssop который может быть установлен в канальный видеорег -MT29F512G08CUCAB - 64GByte

или MT29E1T08CUCCBH8-6 - 1 террабит (128 Гбайт)

Писать в основном h264 а особо интересные моменты ( например по датчику движения) или тревоге без сжатия

Изменено 12 января, 2016 пользователем DSP_ACE

[_Watcher_ 0]

Спасибо за интересные предложения, попробую ответить на все вопросы:

Видеокамеры - только системы PAL.

Размер съемного накопителя должен быть не менее - 8 каналов * 4Мб/с * 3600 секунд * 24 часа * 2 суток = 675 ГБ

Вариант на каждый канал своя Flash карта не подходит.

В идеале устройство должно иметь 2 исполнения - для монтажа в стойку и автономное исполнение (здесь уже хотелось бы размер не 2 U, а более меньший, например http://www.spycams.ru/tsifrovoiy-videoregi...-sky-5108v.html или сопоставимый)

Также хотелось бы увеличивать/уменьшать канальность в зависимости от потребностей - это тоже относится к идеальному устройству.

Управлять регистратором (включение записи, настройка частоты кадров, яркости и т.д. на каждый канал) будет отдельное ПО. Поэтому необходимо будет согласовать протокол взаимодействия. Один возможных это ONVIF.

Также прошу заметить, что в требованиях указан интерфейс Ethernet 100/1000 Мбит/с.

Теперь по поводу реализации на dm365:

Мы в свое время пробовали реализовать регистратор на этом процессоре и столкнулись с рядом проблем:

1. Проблема включения кодека H.264 на частоте 1кадр/сек

2. Проблема периодического потребления кодеком 100% процессора, от чего

возникали проблемы при передаче по сети и с другими процессами.

3. При переключении параметров кодека - тип сжатия, частота кадров,

все подвисало. Мы решили это тем, что при смене этих параметров перезапускаем

кодек заново с новыми параметрами, а не применяем их на лету.

4. Собственно, все проблемы шли от того, что кодек это закрытая бинарная библиотека с кучей багов.

 

Тут хотелось бы задать вопрос DSP_ACE :

Вы пробовали такие сценарии работы регистратора на таком процессоре и сталкивались с такими проблемами и как обходили. (И насколько я помню такие проблемы возникают с аналоговыми камерами PAL, в случае CMOS Sensor таких проблем нет)

 

 

[_4afc_ 25]

(И насколько я помню такие проблемы возникают с аналоговыми камерами PAL, в случае CMOS Sensor таких проблем нет)

 

Почему? Сенсоры подключаются по другому интерфейсу? Имеют низкую частоту кадров? Прогрессивная развёртка?

 

[promo001 0]

Здравствуйте,

Требуется разработка

- питание каждого микрофона 5В, ток не более 10 мА;

- входное сопротивление линейного входа источника аудио сигнала -600±200 Ом;

- питание по выделенным линиям видеокамер напряжением 5 В, ток потребления одной камеры - не более 100 мА;

 

- частота дискретизации звука: 8000 Гц, 11025 Гц, 16000 Гц, 22050 Гц;

- формат: ИКМ16, A-Law, U-Law;

- формат файлов: WAV, WSD;

функцию удаленного перезапуска каждого аудио и видеоканалов.??????

 

Можно использовать за основу любой готовый поддерживаемый и продаваемый регистратор. Цену и сроки обговариваются с возможным исполнителем.

 

1) Чем Вас не устраивают существующие DVR 8 ch D1 (8 ch audio), кроме того, что они уже сняты с производства так как устарели морально?

Все, кроме списка выше в них есть!!!

2) 5В, ток не более 10 мА; - таких активных микрофонов с нагрузкой на длинную линию не бывает! Если только взять электрет с резистором 10кОм...

3) 5 В, ток потребления одной камеры - не более 100 мА; - камера потребляет 0,5Вт??? 0,1А потребляет только выходной транзистор, нагруженный на 75 Ом...

4) Вам действительно нужно так писать звук??? - это другое устройство, оно тоже давно существует.

5) функцию удаленного перезапуска каждого аудио и видеоканалов.?????? - поясните пожалуйста - что Вы имели в виду? передерг питания?