milker

Стандартными - нет. Чуть-чуть нестандартными - да. Операция #1 - копирование. Допустим, наблюдение пишется в папку d:\Video\, а USB диск подключается как e:. Тогда раз в сутки запускаем СуперБатник Copy d:\Video\*.* e:\CopyForOffice\*.* /s Можно ярлык охраннику, а можно и в шедулер - пуск - настройка - панель управления - назначенные задания. Операция #2 - просмотр. Ставим на целевой компьютер Remote ViewLog. Втыкаем диск. Можно скопировать e:\CopyForOffice\ на локальный диск, а можно и так. Запускаем Remote ViewLog. Нажимаем капу "Усиленный" (панель справа, левая во втором ряду сверху), выбираем "База данных перезагрузки"-"Просмотреть каталог записи DVR AVI", через диалог находим нашу папку CopyForOffice, давим Ok. Remote ViewLog от 8.4 очень нестабилен, постоянно падает, есть смысл найти чуть более ранний, из линейки 8.3.x

О, а это уже очень, очень интересно, предметный разговор. Только полянка как раз из тех, для которых за глаза 3-4 кадра в секунду, да и при 45Мбайт/мин получается 65 Гбайт/(камера * сутки), многовато. Думаю, что если зажать fps и качество vbr - можно очень много места сэкономить... Ещё бы интересно ночные съёмки посмотреть - это очень сложно? Тоже ознакомились, много интересного, в т.ч. явно заявлен суммарный fps системы, ограниченный процессором. А вот тут вопрос. i5 бывают разные - 2х и 4х ядерные. О каких идёт речь? Поскольку у меня есть большие сомнения, что 4х ядерный i7, даже с гипертредингом (8 виртуальных ядер), на реальных задачах хотя бы вдвое быстрее чем i5 c теми же 4мя физическими ядрами, но без гипертрединга. Хотя в PDF для i7 указаны вдвое большие fps, чем для Core 2 Quad, это наводит на размышления...

Абсолютно точно не скажу, но имею мнение, что запись трафика с ip камер практически не грузит CPU - он приходит сжатым и уже не пережимается. Поэтому, в первом приближении, обычный офисный комп, но с 4х ядерным i5 (на всякий случай). Основная возможная проблема здесь будет в другом - выдержит ли сеть/дисковая система суммарный трафик со всех камер. Сколько выдают камеры - неизвестно, предположим 160 Мб/5 минут, 0.5 Мб/с, 18 камер - 9 Мб/с - это на пределе теоретической пропускной способности 100 Мбит/с линка. Поднимайте сеть до гигабита, или ограничивайте качество. Второй затык - дисковая подсистема. Современные диски имеют линейный трансфер за 100 Мбайт/с, но при многопоточной работе он падает до 1..10Мбайт/с (ЕДИНИЦ мегабайт/с). Поэтому диски серверные, оптимизированные для многопоточной работы. NCQ помогает, но слабовато. В принципе одного-двух ХОРОШИХ дисков должно хватить, если не хватит - думать про рейд или SAS. Ну и, ознакомившись с первоисточниками - интересная табличка на http://www.geovision.com.tw/english/Prod_GVNVRV84_Spec.asp. Geovision считает нормальным писать 18x25 = 450 fps при 3 мпикс на одиночный жесткий диск (систему лучше положить на отдельный), но в примечаниях еще один интересный момент: === To connect IP cameras with H.264 codec and GV-IP Speed Dome (no matter which codec you select), the minimum CPU requirement of Core 2 Quad can only support up to 8 channels. With CPU of Core i7 or higher, you can record up to 32 channels but note the following limit for live viewing: • For live viewing of 32 channels, you need to lower the resolution and change the codec to MPEG 4 or MJPEG. ===

Этот режим нас не интересует. Не вариант - качества CIF абсолютно недостаточно. У нас теперь широкие каналы. Но никуда не делись требования: 1. Возможности полноценной работы с переданным видео (пишется софтовым DVR от того же Geovision). Посему качество требуется достаточно высокое. 2. По хранению данных в течении нескольких месяцев (до полугода), поэтому сжатие сильное. Софтовый DVR от geovision укладывается, железячный нет. Софтовый после железячного пережимать не умеет. Железячный - в помойку? Заказан, ждём. Будем тестировать. Но, если он жмет D1 @ 5fps так же как и предыдущий... Зависит от сферы применения. На стоянке, товарной ЖД станции или ещё какой промышленной территории 25 fps избыточны. Меня учили, что это нужно для объектов типа казино, в современных реалиях - возможно для супермаркетов, контроля за транспортом там, где он быстро движется - на улицах, магистралях. С другой стороны, в стандартный системник более 4х дисков затруднительно, ёмкости сейчас только-только подошли к 2-3 Тб, десяток Тб - это примерно 2 недели при 16 камерах и 160 Мб/5 минут. Ни о каком архиве, даже на блюрей, речи не идет. Да, закон Мура, каждые 18 месяцев ёмкость жестких дисков удваивается за ту же цену, да, года через три можно будет писать аж два месяца. Но уже сейчас удается запихиваться в около 15Гб/день - "живой" архив месяца на 4 в приемлемом качестве - при существенно менее дорогом дисковом массиве. Не устраивает - получаем слишком низкое качество при фиксации на центральном DVR.

Зверские какие-то режимы. Вполне приемлемое для нужд наблюдения за территорией качество (D1 + 2-3-5fps) укладывается в 0.5-1 Гб/сутки, это 2-4 Мб на пятиминутный ролик (~0.5..1 Мб/минута). Попытки зажать регистратор до аналогичных объемов (<1 Гб/сут) к положительному результату не привели. Максимум - установка VBR на "средний" дает в среднем двукратный выигрыш по объему по сравнению с CBR, обеспечивающим аналогичное качество. Это есть. Но, Во-1 - не надо использовать дешевые камеры. Во-2 - при применении CBR ничего никуда не растёт. Правда и качество не радует, по сравнению с аналогичным по прожорливости VBR режимом... Воооот. Я тоже считаю что корень зла в производительности. Два ядра и 2.4 ГГц на 16 камер - это 300 млн операций в секунду на камеру. 64 битных операций, если я чего понимаю. А с учетом того, что Intel Core умеет вроде как до 4 операций/такт... Против этого 300, или пусть даже 400 МГц процессор cDVR (я как бы на него смотрел) - это 100млн операций на камеру в секунду - и то, в предположении, что один такт == одна операция. Причем, думаю, максимум - 32 битных операций. Т.е. вычислительные ресурсы в пересчёте на канал могут легко отличаться на порядок. У нас тот сжатия немного другие, поэтому картинка по-любому заметно замыленная (но, тем не менее, достаточная). Но полученная с регистратора - в разы большего объема. Насчёт одинаковости - есть сомнения. Дело в том, что H264 - всего лишь расширение mpeg4. Причем большая часть фишек видео наблюдению скорее вредна, поскольку замедляет процессы произвольного позиционирования и просмотра задом наперёд, поэтому, готов спорить, в продуктах Geovision она тупо отключена. Кроме того, жручесть до ресурсов никто не отменял, при прочих равных H264 может потребовать в 2-3 раза больше - а где их взять? Единственная надежна на аппаратные кодеры, которые уже появились. Эх, если бы были известна номенклатура потрохов... В общем, ждём тестов, очень интересно. Социальный заказ - D1, 4 fps, и разные варианты сжатия, из расчёта попадания в 1..2..5 Гб/сут для общего плана двора с периодически-умеренным движением. Это не столько ограничивать, сколько получать гарантированный размер. Причем при равной среднесуточной скорости с VBR "средний" получаем двукратный рост архива (который у cDVR и так не маленький). Применяли, пытаясь уложится в "тонкий" канал связи (похоже что cDVR жмёт поток один раз, далее раскидывая копии пожатого на webcam, ip cam и в запись), с появлением толстого канала, после серии экспериментов - остановились всё-таки на VBR. Тоже не устраивает - при 3-4 fps событие легко может попасть между ключевыми кадрами, и весь смысл архива потеряется.

О. Похожая проблема - что брать из ip устройств. На примере конкретно ощупанного compact DVR: 1. Максимальный битрейт (CBR) D1 - 3 Мбит 2. При уменьшении частоты кадров объем часа видео НЕ МНЯЕТСЯ (что, в общем-то логично, ибо CBR - это constant bitrate), зато при увеличении fps катострофически падает качество (поскольку каждый ключевой кадр приходится ужимать пропорционально увеличению fps). Далее, по ограничению качества. Первичен не занимаемый объем, а именно получение видео качеством не ниже заданного (качество - это детали + fps). Поэтому до бесконечности зажимать поток и fps нельзя. Практика показала, что при равном качестве/разрешении/fps, при использовании VBR, видео с Compact DVR занмает в 5 раз больше места чем записанное с ТОЙ ЖЕ КАМЕРЫ (и неплохой камеры, по крайней мере не шумящей в сумерках), В ТОМ ЖЕ МЕСТЕ на компьютере (10Гб/сут против 2). Качество CBR 1 Мбит/с (укладывающееся в те же 10 Гб/сут) оказалось неудовлетворительным, а 2 Мбит/с - это непотребные 20 Гб/сут, т.е. превышение на порядок. Итог - Compact DVR как переходник аналог --> ip работает абсолютно неудовлетворительно. И очень остро стоит вопрос - хоть какие-то IP устройства от Geovision позволяют получить сжатие, хотя бы приближающееся к получаемому на DVR (компьютере с платами 600-1200 серий и GV 8.x)? Или они все работают на уровне cDVR? Возможности экспериментировать за счёт предприятия нет. Идеально если бы удалось пощупать реальные ролики, записанные ip устройствами (cDVR, DVR, видеосервера, ip камеры) в услових сопоставимых или, лучше, одинаковых сцен. Интересует D1 и fps около 4, хочется уложится в 3-4 Гб/сут.

Если нужен только онлайновый просмотр (без доступа к архиву) - я для фирмы собрал эрзац-квадратор, используя интерфейс webcam (описан в SDK, который раздается с оффсайта по запросу) и возможности hta (можно ограничится html). С пользовательской точки зрения получилась программа - полноэкранный квадратор с камерами разных серверов и некоторыми бонусами - можно просматривать отдельные камеры в увеличенном виде или на весь экран. Разумеется, требуется прохождение ip от клиента до определенных портов серверов, и достаточная толщина канала. За небольшую денежку могу адаптировать к Вашим требованиям, а за более бОльшую - добавить новые фичи. Собственно достаточно посмотреть как внутри устроен код HTML пользовательской страницы webcam - 90% необходимого там уже есть, программер средней руки разберется.