Хабрахабр

Исследование файловой системы HDD видеорегистратора модели QCM-08DL

В конце статьи приводится реализация соответствующей программы на языке С.
Видеорегистратор (сокращённо DVR) QCM-08DL применяется в системах видеонаблюдения и позволяет производить восьмиканальную запись видео и аудио. Данная статья посвящена изучению файловой структуры жёсткого диска восьмиканального видеорегистратора с целью массового извлечения файлов с видеозаписями. Форматом сжатия видео является популярный формат H264. Данная модель, на мой взгляд, одна из самых дешёвых и в тоже время надёжных в эксплуатации. Видео и аудио записываются на стандартный компьютерный SATA жёсткий диск (HDD), установленный внутри DVR. Для аудио применяется формат сжатия ADPCM. Также, имеется возможность извлекать данные в файл на внешний носитель. С помощью самого DVR имеется возможность просматривать записи, производя их поиск по дате и времени. Во-вторых – на компьютер через WEB-интерфейс DVR. Во-первых – на USB накопитель, который подключается к USB интерфейсу DVR. Расширение файла – «. Имя получающегося файла длинное, и в него входит дата записи, время начала и конца, канал записи и прочая дополнительная информация. Исследование содержимого такого файла дало мне понять, что медиа контейнер, в который запакованы аудио и видео потоки, далеко не стандартный. 264». Плеер очень неудобный. Такой файл можно открыть с помощью плеера, который прилагается вместе с видеорегистратором. Данная программа перепаковывает видеопоток, оставляя его в формате H264. Но также, можно воспользоваться программой-перепаковщиком в контейнер AVI, которая также прилагается. В итоге получается .avi файл, воспроизводимый любым стандартным плеером. А звуковой поток преобразует из ADMCM в PCM, увеличивая его в 4 раза по размеру. Она позволяет совершать операции только над одним файлом. Отмечу сразу, что данная программа-перепаковщик весьма неудобная. Для перепаковки множества файлом приходиться открывать их по очереди.

Были поставлены следующие задачи.

  1. Получить с жёсткого диска видеорегистратора доступ ко всем файлам .264, подключив жёсткий диск к компьютеру.
  2. Изучить алгоритм, по которому работает штатная программа-перепаковщик 264-avi и создать такую же программу, которая выполняла бы те же операции, но уже не над одним, а над целой группой файлов, причём одним нажатием.

Первая задача, на первый взгляд, может показаться очень простой: нужно просто подключить HDD к компьютеру и открыть разделы в проводнике. Однако здесь имеются свои подводные камни. Данная статья посвящена именно первой задаче.

Поэтому, разметка жёсткого диска, вероятнее всего, также будет Linux-подобной. Я уже заранее знал, что программная оболочка микроконтроллера видеорегистратора основана на операционной системе, подобной Linux. В моём случае ёмкость HDD – 1TB, компьютер с ОС Xubuntu. Следовательно, потребуется компьютер с ОС Linux. Это явно не то, что нужно. Подключив HDD к компьютеру, мне удалось увидеть всего один раздел на несколько гигабайт. Внутри каждой папки – множество файлов, соответствующие записям. Внутри раздела находится множество папок формата имени «YYYY-MM-DD», соответствующие датам записей. Однако, их размер в разы меньше и расширение не . Файлы одноимённые с теми, которые получаются при извлечении с DVR. Стоит предположить, что эти самые файлы nvr являются ключами для соответствующих файлов 264 (или их медиа потоков), содержимое которых находится на основном пространстве HDD. 264, а .nvr. Данные папки с файлами я скопировал на отдельный носитель для дальнейшего исследования.

В этой статье я попробую рассказать о данной процедуре. Для исследования использовал множество программных инструментов: дисковый редактор (он же и файловый бинарный редактор) DiskExplorer (WinHex я использовал позже), MS Excel для вспомогательных расчётов и фиксации результатов, среда программирования Dev-C++ для написания вспомогательных и окончательных консольных программ и прочее.

Данный сектор, как правило, содержит MBR структуру. Сначала посмотрим на самый первый сектор HDD (один сектор (1 LBA) занимает 512 Байт). Структура этого сектора, а также, структура описания раздела, приведены ниже (взято из Википедии). В неё входит загрузчик и базовое оглавление разделов.

Глядя на рисунок ниже и руководствуясь таблицами выше, мы видим, что загрузчик отсутствует. В случае с исследуемым HDD имеем следующее. Она выделена в красную рамку. Но нас интересует больше таблица разделов. Из таблицы разделов видно, диск поделён на два раздела. Последние два байта (синяя заливка) – сигнатура MBR. Это раздел FAT32. Код типа первого раздела (жёлтая заливка) – 0x0B. Это один из разделов Linux (в смысле, EXT). Код типа второго (оранжевая заливка) – 0x83. Байты кода типа раздела обведены в синюю рамку.

Полная расшифровка сектора MBR с таблицей разделов и их параметрами приведена ниже.

Кстати говоря, в Windows XP также отобразился только первый раздел, но из проводника не открылся. Обращая внимание на размеры разделов (пересчитывая число секторов в гигабайты), несложно догадаться, что на компьютере с ОС Xubuntu отображался именно первый раздел, занимающий незначительную часть дискового пространства. А почему же тогда второй раздел Linux не отобразился в ОС Xubuntu?

Изучив предварительно структуру и организацию линуксовой файловой системы на примере EXT2, я приступил к исследованию второго раздела.

Руководство по файловой системе EXT2 свидетельствует о наличии так называемого суперблока, который располагается в 1024 байтах от начала раздела (то есть в двух секторах от начала). Как видно из таблицы разделов, второй раздел начинается с сектора 16016805. Зато первый сектор 16016805 по своей структуре напоминал суперблок. Однако сектор 16016805+2=16016807 оказался пустым. Суперблок – это основной блок, в котором содержится своеобразная таблица различных констант и параметров для функционирования файловой системы: адреса положений и размеры других необходимых блоков, в частности, заголовков файловых записей и директорий. Но его содержимое полностью не соответствовало описанию содержимого суперблока из руководства. Дальнейшие исследования этого раздела привели меня только к одному выводу: DVR использует свою уникальную файловую систему.

Было обнаружено на секторе 65 (двумя секторами ниже) содержимое, полностью похожее на содержимое суперблока ФС EXT2, которое описано в руководстве. В дальнейшем решил взглянуть на первый сектор первого раздела (сектор 63) и пролистать вниз. Таким образом, первый раздел жёсткого диска видеорегистратора – раздел EXT2, на котором записаны файлы nvr, являющиеся ключами к требуемым видеозаписям. Дальнейшие исследования привели к выводу, что первым разделом HDD DVR является раздел EXT2, который и отображался в ОС Xubuntu, невзирая на метку 0x08 (не EXT) в оглавлении раздела!

264, которые я также предварительно исследовал. Напишу кратко о структуре файлов . Как и в любом медиа контейнере, в «264» присутствует заголовок со служебной информацией и медиа тегами, а также потоки аудио и видео, которые следуют небольшими блоками один за другим. Данная информация в дальнейшем будет необходима для исследования второго раздела HDD. Перед этим словом расположены байты, относящиеся к дате и времени записи. По смещению 0x84 байта от начала файла прописано ключевое слово «MDVR96NT_2_R». После идёт множество байтов нулей. Но эта информация содержится в имени файла, поэтому, особого внимания она здесь не заслуживает. Блоки видеопотока начинаются с 8-байтового заголовка «01dcH264» (встречается также «00dcH264»). Основная информация с аудио и видео потоками берёт начало по смещению 65536 байт. Через 4 байта нулей (00 00 00 00) начинается сам блок видеопотока. Следующие за ним 4 байта описывают размер текущего блока видеопотока в байтах. После – 12 байт информации, которую я пока не разгадал. Блоки аудиопотоков имеют заголовок «03wb» (хотя, по моим наблюдениям, первый символ заголовка в некоторых случаях был необязательно «0»). Какие-либо метки в конце файла отсутствуют. А начиная с 17-ого байта – аудиопоток фиксированной длины 160 байт.

Как уже говорилось выше, содержимое раздела было скопировано на отдельный носитель через обычный проводник в ОС Xununtu. Приступим к исследованию структуры файлов и каталогов, расположенных на первом разделе HDD. Судя по имени, в нём содержится информация о списке файлов в текущем каталоге. В каждом каталоге (директории), помимо файлов nvr содержится один бинарный файл с именем «file_list». рис. Откроем этот файл в бинарном редакторе (см. Я исследовал структуру данного файла, и здесь нет в принципе ничего интересного. ниже). Тем не менее, кратко напишу о данной структуре. Файл не имеет никакой информации, касающейся расположения искомых медиа потоков. Следующие 16 байт имеют отношение к дате и времени и количеству файлов в текущем каталоге. Первые 32 байта – заголовок с какими-то константами. Далее – 8 байт констант, свидетельствующих о начале файловой записи. Далее следуют 48 байт констант. Далее – 24 байта, относящиеся к времени (число секунд, прошедших от начала суток, начала и конца видеозаписи) и прочим атрибутам видеозаписи. Далее – 96 байт, указывающие полный путь к файлу nvr, включая его имя. Их число равняется числу видеозаписей за текущие сутки, на которые указывает имя текущего каталога. И так далее, по аналогии, для всех файлов nvr в текущем каталоге. Видимо, для ускорения поиска видеозаписи внутри интерфейса DVR. Для чего нужен этот файл?

Вид одного такого файла в бинарном (точнее, в 16-ричном) редакторе приведён на рисунке ниже. Перейдём к изучению структуры самих файлов nvr. Это 32-битные (4-байтные) значения, располагающиеся через каждые 32 байта, начиная с байта по смещению 40. Не вдаваясь в подробности описания структуры содержимого (часть которой так и осталась для меня загадкой), я выделил самые основные параметры, которые и являются искомым ключом. В дальнейшем я убедился, что этого вполне достаточно для ключа к видеозаписям. На рисунке они выделены красным прямоугольником. Такая нотация обусловлена архитектурой процессора ПК. Напоминаю, что 4 байта значения этого ключевого параметра располагаются от младшего к старшему, но не наоборот! Он соответствует первой видеозаписи, сделанной видеорегистратором. В приведённом на рисунке примере изображён первый nvr файл первого каталога. Исследуя другие nvr файлы, и просматривая в них именно эти указанные байты, были также замечены целые числа, идущие по возрастанию. Очевидно, что значения параметров, которые я назвал ключевыми, в приведённом примере образуют последовательность целых чисел, начиная с нуля и идущие по порядку по возрастанию. Например (числа от балды): 435, 436, 438, 439, 442,…(или в 16-ричном виде: B3010000, B4010000, B6010000, B7010000, BA010000,…). Но данная последовательность начиналась естественно уже не с нуля, и в некоторых случаях местами наблюдались пропуски по одному или два числа.

То есть, например, если последовательность «435, 436, 438, 439, 442,…» относится к видеозаписи с одного канала, то пропущенные значения (437, 440, 441) будут относиться к видеозаписи с другого канала, которая осуществлялась в тот же момент времени. Такая последовательность с пропусками приходилась на nvr файлы, соответствующие видеозаписям, которые DVR записывал одновременно с двух и более каналов. Не остаётся и сомнений, что приведённые выше числа образуют номера каких-то частей, имеющих отношение к видеозаписям. В этом я сам убедился, просмотрев и сравнив соответствующие nvr файлы, опираясь на их имя. Остаётся только разгадать связь между этими числами и координатами дискового пространства, на котором размещены данные.

Первое предположение – данными являются потоки аудио и видео, которые в контейнере 264 представлены короткими блоками, причём, как было сказано, блоки видеопотока имеют разный размер. Также, предстояло выяснить, какие именно данные делятся на вышесказанные нумерованные сегменты? Второе предположение – потоки аудио и видео DVR упаковывает в контейнер 264 в начале и во время видеозахвата. При этом DVR на этапе извлечения видеозаписи на внешний носитель собирает эти потоки и упаковывает в контейнер 264. 264, который бы получился в результате его извлечения на внешний носитель. И при этом на HDD записываются уже сформированные данные файла . После данного заголовка также присутствовало множество байтов нулей. Исследуя пространство HDD где-то в середине второго раздела, наряду с байтами потоков аудио и видео и их заголовками того же вида, что и в контейнере 264, мне также попадались и заголовки самого контейнера: MDVR96NT_2_R. Поэтому, для получения нужного файла . В целом, исследование показало, что имеет место второй вариант из двух вышеприведённых. 264, вероятнее всего, нужно просто соединить вместе все сегменты, номера которых содержатся в соответствующем файле nvr.

Приступим к поиску зависимости между номером сегмента и координатами на HDD.

Можно сделать предположение о параметре т.н. Начало данных контейнера 264, соответствующего самой первой видеозаписи (там, где нумерация сегментов начинается с нуля) инструментами поиска я нашёл на секторе 16046629 (29824 сектора от начала раздела). начального смещения, который будет участвовать в формуле, описывающей искомую зависимость.

Для этого взглянем на имена файлов. Возьмём два nvr файла, соответствующие видеозаписям с разных каналов, которые DVR захватывал одновременно. Первая запись – запись с 1-ого канала с 16:09:37 по 16:10:35 времени. Например, видеозаписи, на которые указывают файлы «ch00000000000001-150330-160937-161035-02p101000000.nvr» и «ch00000000000004-150330-160000-163000-00p004000000.nvr» велись одновременно. Обе записи сделаны 30. Вторая запись – запись с 4-ого канала с 16:00:00 по 16:30:00 времени. 2015 г. 03. Принимаю во внимание также тот факт, что в меньшем интервале времени (в пересечении двух интервалов) DVR не осуществлял видеозахват ни с одного из остальных 6-ти каналов. На временной шкале, очевидно, временной интервал первой записи является подмножеством временного интервала второй записи. Убедимся, что отсутствующие те самые числа (номера сегментов) во втором длинном файле обязательно присутствуют в первом коротком файле, целиком и полностью. Просмотрим содержимое этих nvr файлов. 264, на которые ссылаются исследуемые файлы nvr. С помощью DVR обычным способом требуется заранее извлечь хотя бы один из файлов . 264». Допустим, извлекли «ch00000000000001-150330-160937-161035-02p101000000. Как уже было сказано, в начале данного файла до ключевого слова «MDVR96NT_2_R» присутствуют уникальные байты, соответствующие дате и времени видеозаписи, содержащейся в данном файле. Откроем его в бинарном редакторе. Также, записываем смещение этой цепочки байт от начала файла. Списываем все эти байты, начиная от ненулевого и кончая заголовком (чем короче цепочка байт, уникальная для данной видеозаписи, тем лучше). 264 присутствуют лишние 4 байта нулей. Следует обратить особое внимание, что в начале извлечённого файла . 264 и сектор дискового пространства, с которого начинаются данные содержимого одного из файлов . Это стало заметно, сравнивая первые 512 байт файла . То есть, информация в файле . 264 (файл практически любой ФС всегда начинается в начале сектора, мало того, – кластера). Размер (в байтах) любого файла . 264 сдвинута заранее на 4 байта вправо. Приступим к поиску сектора, с которого начинается исследуемый файл . 264 кратен 512 только после предварительного вычитания числа 4 из размера. В дисковом редакторе запускаем функцию поиска. 264. Для ускорения поиска вписываем в поле «искать по смещению» значение смещения, предварительно вычитая 4. В поле искомого значения вписываем уникальную цепочку байт, списанную заранее. Через несколько часов поиск завершился удачно. Запускаем поиск. Пусть это будет значение s. Записываем номер сектора, в котором найден уникальный заголовок. Списываем номер первого сегмента (4 байта по смещению 40). Смотрим содержимое файла nvr для этой видеозаписи. Итого, пока у нас известны номер сектора диска (16046629) для нулевого номера сегмента (в самой первой видеозаписи) и номер найденного сектора диска s для только что списанного номера сегмента b. Пусть это будет значение b. Вычислив, получил значение 128. Можно вычислить предполагаемый размер сегмента: (s-16046629)/(b-0). Таким образом, размер сегмента равен 128 дисковым секторам (LBA), или 128*512=65536 байт!

Он описан ниже. Я провёл ещё один дополнительный интересный эксперимент, чтобы окончательно развеять все сомнения.

264, который начинается с данного сектора. От начала сектора s выделим область на диске, размером, сравнимым с размером файла . 264, который захватывался на HDD одновременно с первым. Если мои догадки верные, то в выделенную область попадут сегменты другого файла . Порежем получившийся образ на файлы по 65536 байт (размер сегмента). Сохраним эту область в файл (создадим образ). Пусть это будут куски M1, M2, M3,…. Это можно сделать с помощью функции «Разбить файл» в Total Commander. 264 (который был по-юзерски извлечён с DVR), но убрав предварительно 4 байта нулей вначале. Точно также порежем исследуемый файл . С помощью функции «Сравнить по содержимому» в Total Commander сравним по очереди куски образа и куски от файла . Пусть это будут куски K1, K2, K3,…. (M1 с K1, M2 с K2 и т.д.), руководствуясь номерами сегментов из соответствующего файла nvr. 264. Допустим (числа от балды), цепочка чисел в nvr следующая: 435, 436, 438, 439, 442,… При таком раскладе M1=K1, M2=K2, M4=K3, M5=K4, M8=K5,…. При этом получается следующее. 264 оказываются равными между собой, учитывая соответствующее опережение по номерам кусков файла-образа, согласно пропускам чисел в последовательности. То есть, кусочки, на которые разбивался файл-образ и файл . Вот так вот!

Размер сегмента – 128 секторов. Итого, мы получили предполагаемую зависимость: S=16046629+128*d, где d – номер сегмента в файле nvr, а S – номер сектора на HDD, начиная от самого начала диска, с которого начинаются данные содержимого сегмента. Зависимость найдена только для конкретного примера с HDD на 1TB. Приведённая выше формула не берёт во внимание существование второго раздела. Возможно, если поставить в DVR HDD другой ёмкости, константы примут иной вид.

264, руководствуясь соответствующим файлом nvr. Чтобы убедиться в справедливости формулы, вычислим позицию первого сегмента какого-либо другого произвольного файла . 264, находящемся на вычисленном секторе. Обращая внимание на дату и время в имени файла, сравним их с первыми байтами в заголовке . Следовательно, «попали в точку»! Байты, кодирующие по отдельности число, месяц, год, часы, минуты, секунды, соответствуют временным данным в названии файла. 264, количество сегментов cs. Подсчитаем в файле nvr, соответствующем извлечённому заранее файлу . Если файл . Вообще, их число равно cs = sf/32-1, где sf – размер файла nvr. И это действительно так! 264 состоит из cs сегментов, то его размер должен быть равен cs*65536+4 (число сегментов, умноженное на размер сегмента в байтах, плюс 4 тех самых байта нулей).

Как уже отмечалось ранее, нечто похожее на суперблок находится прямо в первом секторе раздела (16016805). Всё-таки, попытаемся исследовать второй раздел. Очевидно, ненулевая основная информация находится в первом секторе суперблока. А его точная копия была обнаружена семью секторами ниже (16016812). Его вид в дисковом редакторе приведён на рисунке ниже.

Голубым цветом выделены дата и время монтирования раздела. Часть 4-байтных параметров я сумел расшифровать. В приведённом примере «03 7E 74 54» (десятичное значение 1416920579) соответствует «Tue, 25 Nov 2014 13:02:59 GMT». Дата и время представлены в специальной нотации «Unix time» (число секунд, прошедших с полуночи 1 января 1970 года). В фиолетовой рамке обведено значение 65536. Для перевода значений я пользовался специальным онлайн калькулятором. В зелёную рамку выделены значения 1. Возможно, именно на эту позицию суперблока ссылается интерпретатор файловой системы внутри программы DVR, когда считывается размер блока (в предыдущем контексте я называл блоки сегментами). битовой карты (в количествах блоков от начала раздела). Одно из них наверняка обозначает положение начала т.н. В красную рамку выделено значение 233. Действительно, заранее было обнаружено начало информации нечто похожей на битовую карту на секторе 16016933 (16016805+128*1). 264 от начала раздела: 16016805+128*233=16046629. Это как раз и есть позиция начала данных видеозаписей .

В нём есть суперблок, его копия, битовая карта. То есть, второй раздел можно назвать урезанным и немного видоизменённым разделом EXT2. н. Но отсутствуют т. Раздел содержит данные файлов . информационные узлы, соответствующие файловым записям. Может быть, существует более грамотная формулировка? 264 (аудио и видео потоки), но информационные узлы (скажем так) для этих данных размещены в nvr файлах на первом разделе. Но мне это уже не столь важно.

264. Напишем простую программу для массового извлечения файлов . Программа сканирует все файлы nvr, скопированные заранее на раздел 1TB нового HDD. Сразу говорю, что большого опыта в программировании по Windows у меня нет. 264 с тем же именем в том же каталоге, используя обращение к секторам оригинального HDD. Анализируя их, программа создаёт файл . Можно было в данную программу включить алгоритм работы с первым линуксовым разделом для доступа к файлам nvr, чтобы не прибегать к их предварительному копированию. Предварительно в пустом разделе нового HDD создана папка с именем «DVR», в которую помещены папки по датам, что скопированы «обычным способом» в Линуксе. Да, можно было, но мне на тот момент хотелось сделать всё как можно быстрее. А ещё можно было добавить другие удобные фишки.

Соответственно, я применил два цикла: пробег по папкам, пока они не закончатся, и пробег по файлам в каждой папке с тем же условием. Для сканирования директорий я не использовал рекурсию, принимая во внимание, что формат директорий фиксирован и имеет два уровня вложения. Для работы с секторами HDD я использовал функционал WinAPI по аналогии работы с файлами. Для чтения файлов я применил сишную функцию fopen. Перейдём к коду программы.

Библиотеки нужны такие.

#include <windows.h>
#include <stdio.h>
#include <string.h>

А эти функции я полностью скопировал с какого-то форума.

HANDLE openDevice(int device) { HANDLE handle = INVALID_HANDLE_VALUE; if (device <0 || device >99) return INVALID_HANDLE_VALUE; char _devicename[20]; sprintf(_devicename, "\\\\.\\PhysicalDrive%d", device); // Creating a handle to disk drive using CreateFile () function .. handle = CreateFile(_devicename, GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL); return handle;
} HANDLE openOutputFile(const char * filename)

В функцию копирования заключена формула линейной зависимости, которая фигурировала в теории выше.

void copy(HANDLE device, HANDLE file, unsigned long int s){ LONG HPos; LONG LPos; __int64 sector; sector = 16046629+128*s; HPos = (sector*512)>>32; LPos = (sector*512); SetFilePointer (device, LPos, &HPos, FILE_BEGIN); DWORD dwBytesRead; DWORD dwBytesWritten; unsigned char buf[65536]; ReadFile(device, buf, 65536, &dwBytesRead, NULL); WriteFile(file, buf, dwBytesRead, &dwBytesWritten, NULL);
}

Основная функция также довольно простая.

int main(){ HANDLE hdd = openDevice(1); //Здесь надо указать номер HDD от DVR, который прописался в системе; SetFilePointer (hdd, 0, NULL, FILE_BEGIN); DWORD dwBytesRead; char name[100]; unsigned int bl; //Пробег по блокам; unsigned int N; //Число блоков; unsigned long int pt; //Указатель на блок; WIN32_FIND_DATA fld,fld1; //Структура с файлом nvr или с папкой; HANDLE hf,hf1; hf=FindFirstFile("E:\\DVR\\*",&fld); FindNextFile(hf,&fld);//Пропускаем "."; FindNextFile(hf,&fld);//Пропускаем ".."; do{ char *str = new char; sprintf(str,"%s%s%s","E:\\DVR\\",fld.cFileName,"\\*.nvr"); printf("\n\nFOLDER: %s\n\n",str); hf1=FindFirstFile(str,&fld1); do{ FILE *nvr; sprintf(name,"%s%s%s%s","E:\\DVR\\",fld.cFileName,"\\",fld1.cFileName); nvr=fopen(name,"rb"); name[strlen(name)-3]='2'; //Путь и имя сохраняем, но name[strlen(name)-2]='6'; //корректируем разширение; name[strlen(name)-1]='4'; HANDLE out = openOutputFile(name); SetFilePointer(out, 4, NULL, FILE_BEGIN); //Как в "оригинале", оставляем 4 нулевых байта в выходном файле (для полного соответствия); bl=0; N=fld1.nFileSizeLow/32-1; //Расчёт количества блоков (кусков); printf("\t%s\n\t%i Blocks\n\n",fld1.cFileName,N); for(bl=0;bl<N;bl++){ //Пробег по блокам; fseek(nvr,40+32*bl,SEEK_SET); //Позиционируемся; fread(&pt,1,4,nvr); //Считываем номер; copy(hdd,out,pt); //Копируем по номеру; } CloseHandle(out); fclose(nvr); }while(FindNextFile(hf1,&fld1)); FindClose(hf1); delete str; }while(FindNextFile(hf,&fld)); FindClose(hf); CloseHandle(hdd); system("PAUSE"); return 0;
}

На старом компьютере с процессором Pentium 4 и PCI контроллером SATA программа успешно переложила до конца заполненный HDD несколькими тысячами файлов .264 в среднем за 7 часов. На новом компьютере – раза в три быстрее. Как я уже отметил, программа не универсальная, все константы и переменные подстроены под мой конкретный случай с HDD на 1TB. Однако, можно ещё немного поработать и сделать её универсальной, нарисовать к ней графический интерфейс.

Во второй части статьи я напишу, как «своими руками» осуществить перепаковку из контейнера «264» в стандартный контейнер «avi».

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть