Как открыть жесткий диск с видеорегистратора на компьютере
Есть три офиса в разных городах, в них хочу поставить видеонаблюдение по 2 камеры на офис, и чтобы запись с этих камер велась, скажем, у меня дома на сервер. Собрать компьютер, на который будет вестись запись. Что нужно для такой организации видеонаблюдения или есть способ который будет проще? Может кто-то может даже посоветовать определенные модели оборудования? Важно качество звука и картинки.
Если вам важно качество звука и картинки, при этом вы хотите писать с шести камер, то домашний сервер - исключается. Подпишитесь на сервис "облачного" видеонаблюдения, например - ivideon. Купите совместимые с ним камеры, которые могут работать с ним без дополнительных компьютеров, качество картинки с которых вас устраивает. Подключите камеры к сервису, и наслаждайтесь.
Только имейте в виду, что хорошая картинка жрёт трафик, у ваших офисов либо всё остальное тормозить начнёт, либо видео будет проседать, когда там что-то качать будут.
Мне важно, чтобы не платить ежемесячные расходы дополнительно и, чтобы запись с камер была у меня, а не где-то там
Дмитрий, а доступ в интернет у вас везде бесплатный и толщина каналов достаточная для реализации вашей задачи? Что-то мне подсказывает, что вы это даже не пытались посчитать.
Опишу типовое решение вашей задачи (т.е. решение может быть другим, со своими плюсами и минусами, но в моей реальности чаще всего встречается такое):
Вся запись ведётся локально. В каждом офисе ставится отдельный дешевый видеорегистратор с жестким диском. Видеорегистратор подключен в локальную сеть офиса и через роутер имеет доступ в интернет, на роутере можно пробросить порты для удалённого доступа к регистратору. Дальше разные варианты.
1. с точки зрения типа камер (самостоятельно гуглить плюсы и минусы):
1.1. ip-камеры, подключены в локальную сеть офиса; для них регистратор - NVR или гибридный;
1.2. по-прежнему актуальны AHD-камеры - подключаются к регистратору старым добрым коаксиальным кабелем; регистратор - поддерживающий AHD или гибридный;
2. с точки зрения доступа к видео с вашего домашнего компа:
2.0 в большинстве случаев постоянный доступ никому не нужен; позвонили из офиса "у нас происшествие, надо посмотреть" - заходим удалённо и смотрим, если надо скачиваем нужный кусок записи себе на компьютер.
2.1 у большинства регистраторов есть возможность подключаться к облаку, ну и вы со своего компьютера или смартфона можете зайти на облако и смотреть картинку в реальном времени. Для обычного офиса вполне допустимо - вряд ли китайцы найдут там интересные для себя секреты :)
2.2 поставить дома регистратор - железный или программный - и прописать в нем доступ к удалённым регистраторам. Потребуются статические белые ip-адреса в каждом офисе (хотя есть DDNS, но по мне DDNS это ненадёжный глючный вариант). Минус варианта 2.2 - постоянный трафик.
P.S. ip-камеры умеют отдавать одновременно два потока - "жирный" основной для локальной записи с хорошим качеством и "тощий" альтернативный поток с картинкой похуже для передачи через интернет, чтоб не сильно забивать канал.
Дмитрий, T9? ;)
Про ivideon вы промахнулись с вопросом, это у предыдущего отвечающего надо спрашивать, он же предложил ivideon.
Флешка в камере - как бы это сказать. Ну это не штатный вариант записи, а просто "last resort". Во многих камерах не делают слот под флешку, т.к. давно уже никто это всерьёз не воспринимает. Флешки умирают часто и внезапно. Нормальный вариант чтобы прилепить на шкафу мелкую камеру с флешкой и аккумулятором и пошпионить за кем-то день-два ;) Но постоянное видеонаблюдение на флешку - забудьте.
опишите типичный сценарий глюка, пожалуйста, а так же оцените в конкретных цифрах то, что вы подразумеваете под "надежностью" подобного рода решений.
hint000, что-то мне подсказывает, что опечатка имеет непосредственное отношение к тому, какого рода "офисы" у автора вопроса в разных городах, и почему ему важно собственное хранилище.
CHolfield, я вовсе не хотел сказать, что ненадёжен DDNS, как технология, как протокол. Но реализация в дешевых китайских видеорегистраторах (noname, выпускаемый под десятками разных локальных "брендов") не вызывает у меня доверия. (А чаще всего именно такие устройства ставят в малом и даже в среднем бизнесе - каждая копейка экономится)
В регистраторе обычно прописано несколько известных (китайцам) сервисов DDNS и нет возможности добавить свой. И получается примерно такая ситуация: прошивка для регистратора вышла 2-3 года назад (и обновлений нет, конечно), в ней прописано на выбор например аж 6 всяких сервисов DDNS, из них половина на данный момент уже совсем не работает, еще два как бы работают, но зарегистрироваться не удаётся. Остаётся один рабочий вариант - да и тот удаляет учётную запись если не было никакой активности пару месяцев (условно, точных цифр уже не помню).
Конечно, можно взять приличный роутер и разруливать DDNS средствами роутера, но это отдельный разговор.
Да и не отменяет ненадёжности самих бесплатных сервисов DDNS - за бесплатно какой спрос? А поднимать свой собственный DDNS - это совсем другой уровень компетенций, инфраструктуры и обслуживания.
Если вы купите ip камеры с поддержкой одновременного подключения то вам повезло (такие точно есть, у них по две ссылки для rtsp, у дешевых тоже может быть но в документации про это будет ни слова, в общем берете камеру из прайса, гуглите rtsp изучаете отзывы и т.п. в некоторых случаях это даже зовут хаком, осторожно, большинство ip камер отдают rtsp без авторизации либо авторизация сложно автоматизируется, без шифрования потока и т.п. в общем очень странно сеть камер делать открытой для мира).
Для просмотра видео просто подключаетесь с помощью любого плеера (тот же vlc или mplayer или ffplay) по rtsp по второму линку к камере. Настройте себе прямо в проводнике линки либо простейшую html страничку (гуглите проигрывание rtsp в браузере, почти наверняка это будет flash плеер но с управлением по javascript), где ссылка - это будет картинка с тех же камер, обычно камеры отдают текущую картинку в виде jpeg по спец ссылке. В простом виде задача не выглядит сложной (если только смотреть), но если вам нужно еще и управление (повортные камеры, вкл/выкл led освещение, ночное видение, зум и т.п.) то тогда придется заморочиться и изучать api этих камер (отреверсить их html страничку, скорее всего там простые post запросы). Я бы рекомендовал на своей управляющей страничке сделать ссылки на админку каждой камеры, т.е. ничего програмировать не придется, тупо указать список ссылок на html страничке и все.
Если камера не умеет второй поток, в теории можно собрать из ffmpeg прослойку (на сервере где храните видео), но везде где я видел примеры либо неочевидные глюки либо очень большая задержка (в десяток секунд) трансляции.
В общем не экономьте на камере и не гонитесь за wifi в них, смысла в этом никакого, так как электричество все равно нужно подводить, лучше следите чтобы была возможность питания по POE, т.е. 1 провод на сеть и питание (следите за совпадение стандартов на свитче и камере, бывают у них стоят свои нестандартные сплиттеры).
1. Запускаем программу DiskPlayer. Появится диалоговое окно для ввода имени пользователя и пароля. (Примечание. Имя пользователя по умолчанию - admin, пароль - admin). Поставьте галочку "Сохр. пароль", если не хотите при каждом запуске приложения вводить имя пользователя и пароль.
2. Если HDD будет распознан, в интерфейсе будет отображен соответствующий значок.
3. При нажатии дважды ЛКМ (левой кнопки мыши), выпадет дерево файлов и каталогов. Каждый каталог будет соответствовать дате записи. При двойном нажатии ЛКМ, обозначающего дату записи, будет отображены каналы, дальше отрезки времени записи. По умолчанию длина записи равна 1 (одному) часу.
4. Выберите в правой части программы окно, в котором будет отображаться видео. Двойным нажатием ЛКМ запустите нужный файл для воспроизведения.
5. Для копирования файлов с HDD на компьютер надо нажать ПКМ (правой клавиши мыши) на файле записи, при этом появится следующее меню:
Примечание: можно выбрать только тот отрезок времени, который попадает в диапазон выбранного Вами файла. Например, если Вы выбрали файл 10.00.00-11.00.00, то надо выбрать отрезок времени между этими числами. Иначе программа выдаст ошибку.
Данная программа имеет больше возможностей по сравнению с DiskPlayer и более удобна в пользовании. Производитель утверждает, что данная программа также подходит для автомобильных видеорегистраторов. Но практика показала, что данная программа менее устойчива и недоработана. По поводу автомобильного видеоргеистратора не уверен, не на чем проверить. Замечены зависания и вылетания программы на Рабочий стол. Но для копирования файлов с жесткого диска видеорегистратора она вполне годится и, по моему мнению, удобней чем DiskPlayer.
1. Если диск будет распознан программой, то в левой части интерфейса будет отображен каталог файлов, каждый из которых будет обозначать дату записи.
2. При двойном нажатии ЛКМ, обозначающего дату записи, будет отображены каналы, дальше отрезки времени записи.
3. В нижней части интерфейса присутствует графическая навигация по времени записи (удобней чем в DiskPlayer). Чуть левее можно выбрать дату просмотра записи по календарю. Если в этот день есть запись, то на календаре этот день будет выделен цветом. Кстати, отдельно воспроизвести определенный канал программа не позволяет. Скорее всего недоработка программистов.
Уже много лет к нам в лабораторию DATALABS приносят на восстановление данных диски и флешки из систем видеонаблюдения. Это и стационарные видеорегистраторы и автомобильные регистраторы. В большинстве своём однодисковые, но бывают и много дисковые, а автомобильные как правило с microSD.
Под катом обзор как происходит процесс восстановления.
Проблемы потери данных бывают разные:
1. Инициализация Windows.
Пример нулевого сектора Avtech AVC-776
2. Носороги полазили по меню.
Данные на диске были. Но не квалифицированные люди нечаянно или преднамеренно нажимают очистку диска в меню самого регистратора. Это пожалуй, наиболее страшные случаи, с точки зрения сложности восстановления данных. Так как трутся основные служебные данные, календари, атрибуты заполненности и прочие прелести.
Тут придётся серьёзно реинжинирить устройство хранения данных на диске. Наивный народ натравливает обычные программы для восстановления, но естественно получает банан. У 95% видеорегистраторов не используются типичные файловые структуры, не смотря что у всех написанно что ос Linux, не факт что используется ext2/3/xfs. Так что искать файлы бессмысленно.
Восстанавливать можно двумя способами, разобраться как описывается поток, либо резать сам поток. Второе в большинстве случаев проще, найти где описание номера камеры и раскидать поток по камерам, потом отконвертировать полученные файлики в удобоваримый формат тем же виртуалдабом или аналогичным софтом. В обоих случаях придётся писать софт.
Подводные камни могут быть такие: не всегда можно программно эмулировать работу процессора регистратора, то есть программа кодирования не сможет его конвертнуть, тут можно попробовать скормить эти файлики софту от производителя вирега (если таковой имеется). Этот софт может и не проглотит поток в тупую, нужно будет скачивать с самого регистратора бэкап файлы и смотреть их структуру. При бэкапе регистратор может формировать шапку над потоком нужно будет разбираться с этой шапкой, что бы формировать свою. Самое страшное когда эти файлы сразу конвертятся допустим в avi, и поток там уже не такой как на диске, для анализа не подойдёт.
Хоть что-то приятное в современных регистраторах есть, большинство пишут в кодаке H.264 и софт кодирования спокойно проглотит поток, или вообще халява когда можно дать файлу с потоком расширение mpeg и скормить Vlc… Но опять же не забываем про камеры, может быть один кадр с одной камеры, за ним один кадр с другой и т.д., а может быть по 25 кадров, а может вообще кусками по времени.
Если с потоком ничего не получилось, нужно заставить регистратор показывать данные. С точки зрения реинжиниринга это самое сложное. Разобраться где и как описываются данные, написать софт который это заново сгенерит, вдуть обратно в регистратор, иногда не это уходят недели, а клиентам как обычно нужно срочно… ведь скоро суд))) (чуть не написал судный день))
Слава богу если софт под такой регистратор уже написан, рисёрчить ничего не надо, но разнообразие регистраторов велико и у нас что ни кейс, то праздник.
3. Прошёл цикл.
4. Сломался сам регистратор.
Ну тут восстанавливать ничего не надо, данные то на диске остались. Однако бывает засада, что на сайте производителя нет ПО способного отображать видео с диска, тогда либо искать точно такой же видеорегистратор, либо всё-таки восстанавливать данные, вышеописанными способами.
5. Автомобильные.
Если вы не помните свой пароль, то введите ваш email и получите ссылку для входа. После авторизации укажите свой новый пароль в настройках профиля.
Добрый день.
Подскажите пожалуйста, делать архив времени не было, просто заменил диск в регистраторе. Сейчас есть задача просмотреть снятый с регистратора диск на ПК. Подключаю диск к компьютеру через переходник SATA-USB, запускаю DiskPlayer, но прога ничего не видит. На диске файловая система определяется как RAW, в Linux тоже не читается. Как просмотреть записи на диске?
Спасибо.
dendyru Ответить Подключил Диск по SATA, установил проигрыватель, но ничего не изменилось. Диск системой виден как и был виден через USB-SATA. Программа диска не видит.
Антон_тех.поддержка Ответить Жёсткий диск должен бытть подключен к САТА, как Ваш компьютерный.
Какую модель жёсткого диска используете?
Антон_тех.поддержка Ответить Если б регистратору было всё равно куда писать, тогда и списка рекомендованных не было б.
Чем отличаются рекомендованные от не рекомендованных можете у нас на форуме почитать, много раз это объяснялось уже. И с использованием не рекомендованных никто Вам не гарантирует корректную работу, использование такого жёсткого диска Вами это на свой страх и риск. Вы вначале используете, то что не предназначено для видеонаблюдения, а потом спрашиваете как данные снять.
Работа с DiskPlayer просто до безобразия. Подключается жёсткий диск рекомендованный использовавшийся для записи в регистраторе по САТА, как обычный жёсткий диск к компьютеру. Система у Вас его увидит физически, но не увидит на нём файловую систему. Запускаете DiskPlayer в правой её части будет экран разделённый на 4 части, влевой появится дерево жёсткого диска. Всё. тут никаких манипуляций хитрых проводить не надо. Проверялось с рекомендованными хардами (других не используем) на Win7 и XP всё прекрасно работает.
Отюсда логическим путём делаем вывод, что у нас и у Вас разниться по данному вопросу.
ПО DiskPlayer - одно и то же
ОС Windows (если у вас Win7 либо XP) - одно и тоже
HDD - разные
Вывод: причиной скорей всего является использование не рекомендованного жёсткого диска.
Были поставлены следующие задачи.
- Получить с жёсткого диска видеорегистратора доступ ко всем файлам .264, подключив жёсткий диск к компьютеру.
- Изучить алгоритм, по которому работает штатная программа-перепаковщик 264-avi и создать такую же программу, которая выполняла бы те же операции, но уже не над одним, а над целой группой файлов, причём одним нажатием.
Для исследования использовал множество программных инструментов: дисковый редактор (он же и файловый бинарный редактор) DiskExplorer (WinHex я использовал позже), MS Excel для вспомогательных расчётов и фиксации результатов, среда программирования Dev-C++ для написания вспомогательных и окончательных консольных программ и прочее. В этой статье я попробую рассказать о данной процедуре.
Сначала посмотрим на самый первый сектор HDD (один сектор (1 LBA) занимает 512 Байт). Данный сектор, как правило, содержит MBR структуру. В неё входит загрузчик и базовое оглавление разделов. Структура этого сектора, а также, структура описания раздела, приведены ниже (взято из Википедии).
В случае с исследуемым HDD имеем следующее. Глядя на рисунок ниже и руководствуясь таблицами выше, мы видим, что загрузчик отсутствует. Но нас интересует больше таблица разделов. Она выделена в красную рамку. Последние два байта (синяя заливка) – сигнатура MBR. Из таблицы разделов видно, диск поделён на два раздела. Код типа первого раздела (жёлтая заливка) – 0x0B. Это раздел FAT32. Код типа второго (оранжевая заливка) – 0x83. Это один из разделов Linux (в смысле, EXT). Байты кода типа раздела обведены в синюю рамку.
Полная расшифровка сектора MBR с таблицей разделов и их параметрами приведена ниже.
Обращая внимание на размеры разделов (пересчитывая число секторов в гигабайты), несложно догадаться, что на компьютере с ОС Xubuntu отображался именно первый раздел, занимающий незначительную часть дискового пространства. Кстати говоря, в Windows XP также отобразился только первый раздел, но из проводника не открылся. А почему же тогда второй раздел Linux не отобразился в ОС Xubuntu?
Изучив предварительно структуру и организацию линуксовой файловой системы на примере EXT2, я приступил к исследованию второго раздела.
Как видно из таблицы разделов, второй раздел начинается с сектора 16016805. Руководство по файловой системе EXT2 свидетельствует о наличии так называемого суперблока, который располагается в 1024 байтах от начала раздела (то есть в двух секторах от начала). Однако сектор 16016805+2=16016807 оказался пустым. Зато первый сектор 16016805 по своей структуре напоминал суперблок. Но его содержимое полностью не соответствовало описанию содержимого суперблока из руководства. Суперблок – это основной блок, в котором содержится своеобразная таблица различных констант и параметров для функционирования файловой системы: адреса положений и размеры других необходимых блоков, в частности, заголовков файловых записей и директорий. Дальнейшие исследования этого раздела привели меня только к одному выводу: DVR использует свою уникальную файловую систему.
В дальнейшем решил взглянуть на первый сектор первого раздела (сектор 63) и пролистать вниз. Было обнаружено на секторе 65 (двумя секторами ниже) содержимое, полностью похожее на содержимое суперблока ФС EXT2, которое описано в руководстве. Дальнейшие исследования привели к выводу, что первым разделом HDD DVR является раздел EXT2, который и отображался в ОС Xubuntu, невзирая на метку 0x08 (не EXT) в оглавлении раздела! Таким образом, первый раздел жёсткого диска видеорегистратора – раздел EXT2, на котором записаны файлы nvr, являющиеся ключами к требуемым видеозаписям.
Перейдём к изучению структуры самих файлов nvr. Вид одного такого файла в бинарном (точнее, в 16-ричном) редакторе приведён на рисунке ниже. Не вдаваясь в подробности описания структуры содержимого (часть которой так и осталась для меня загадкой), я выделил самые основные параметры, которые и являются искомым ключом. Это 32-битные (4-байтные) значения, располагающиеся через каждые 32 байта, начиная с байта по смещению 40. На рисунке они выделены красным прямоугольником. В дальнейшем я убедился, что этого вполне достаточно для ключа к видеозаписям. Напоминаю, что 4 байта значения этого ключевого параметра располагаются от младшего к старшему, но не наоборот! Такая нотация обусловлена архитектурой процессора ПК. В приведённом на рисунке примере изображён первый nvr файл первого каталога. Он соответствует первой видеозаписи, сделанной видеорегистратором. Очевидно, что значения параметров, которые я назвал ключевыми, в приведённом примере образуют последовательность целых чисел, начиная с нуля и идущие по порядку по возрастанию. Исследуя другие nvr файлы, и просматривая в них именно эти указанные байты, были также замечены целые числа, идущие по возрастанию. Но данная последовательность начиналась естественно уже не с нуля, и в некоторых случаях местами наблюдались пропуски по одному или два числа. Например (числа от балды): 435, 436, 438, 439, 442,…(или в 16-ричном виде: B3010000, B4010000, B6010000, B7010000, BA010000,…).
Также, предстояло выяснить, какие именно данные делятся на вышесказанные нумерованные сегменты? Первое предположение – данными являются потоки аудио и видео, которые в контейнере 264 представлены короткими блоками, причём, как было сказано, блоки видеопотока имеют разный размер. При этом DVR на этапе извлечения видеозаписи на внешний носитель собирает эти потоки и упаковывает в контейнер 264. Второе предположение – потоки аудио и видео DVR упаковывает в контейнер 264 в начале и во время видеозахвата. И при этом на HDD записываются уже сформированные данные файла .264, который бы получился в результате его извлечения на внешний носитель. Исследуя пространство HDD где-то в середине второго раздела, наряду с байтами потоков аудио и видео и их заголовками того же вида, что и в контейнере 264, мне также попадались и заголовки самого контейнера: MDVR96NT_2_R. После данного заголовка также присутствовало множество байтов нулей. В целом, исследование показало, что имеет место второй вариант из двух вышеприведённых. Поэтому, для получения нужного файла .264, вероятнее всего, нужно просто соединить вместе все сегменты, номера которых содержатся в соответствующем файле nvr.
Приступим к поиску зависимости между номером сегмента и координатами на HDD.
Начало данных контейнера 264, соответствующего самой первой видеозаписи (там, где нумерация сегментов начинается с нуля) инструментами поиска я нашёл на секторе 16046629 (29824 сектора от начала раздела). Можно сделать предположение о параметре т.н. начального смещения, который будет участвовать в формуле, описывающей искомую зависимость.
Я провёл ещё один дополнительный интересный эксперимент, чтобы окончательно развеять все сомнения. Он описан ниже.
Итого, мы получили предполагаемую зависимость: S=16046629+128*d, где d – номер сегмента в файле nvr, а S – номер сектора на HDD, начиная от самого начала диска, с которого начинаются данные содержимого сегмента. Размер сегмента – 128 секторов. Приведённая выше формула не берёт во внимание существование второго раздела. Зависимость найдена только для конкретного примера с HDD на 1TB. Возможно, если поставить в DVR HDD другой ёмкости, константы примут иной вид.
Всё-таки, попытаемся исследовать второй раздел. Как уже отмечалось ранее, нечто похожее на суперблок находится прямо в первом секторе раздела (16016805). А его точная копия была обнаружена семью секторами ниже (16016812). Очевидно, ненулевая основная информация находится в первом секторе суперблока. Его вид в дисковом редакторе приведён на рисунке ниже.
То есть, второй раздел можно назвать урезанным и немного видоизменённым разделом EXT2. В нём есть суперблок, его копия, битовая карта. Но отсутствуют т. н. информационные узлы, соответствующие файловым записям. Раздел содержит данные файлов .264 (аудио и видео потоки), но информационные узлы (скажем так) для этих данных размещены в nvr файлах на первом разделе. Может быть, существует более грамотная формулировка? Но мне это уже не столь важно.
Для сканирования директорий я не использовал рекурсию, принимая во внимание, что формат директорий фиксирован и имеет два уровня вложения. Соответственно, я применил два цикла: пробег по папкам, пока они не закончатся, и пробег по файлам в каждой папке с тем же условием. Для чтения файлов я применил сишную функцию fopen. Для работы с секторами HDD я использовал функционал WinAPI по аналогии работы с файлами. Перейдём к коду программы.
Библиотеки нужны такие.
А эти функции я полностью скопировал с какого-то форума.
В функцию копирования заключена формула линейной зависимости, которая фигурировала в теории выше.
Основная функция также довольно простая.
На старом компьютере с процессором Pentium 4 и PCI контроллером SATA программа успешно переложила до конца заполненный HDD несколькими тысячами файлов .264 в среднем за 7 часов. На новом компьютере – раза в три быстрее. Как я уже отметил, программа не универсальная, все константы и переменные подстроены под мой конкретный случай с HDD на 1TB. Однако, можно ещё немного поработать и сделать её универсальной, нарисовать к ней графический интерфейс.
Читайте также: