Дослідження файлової системи HDD відеореєстратора моделі QCM-08DL

Дана стаття присвячена вивченню файлової структури жорсткого диска восьмиканального відеореєстратора з метою масового вилучення файлів з відеозаписами. В кінці статті приводиться реалізація відповідної програми на мові С.

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

Були поставлені наступні завдання.

  1. Отримати з жорсткого диска відеореєстратора доступ до всіх файлів .264, підключивши жорсткий диск до комп’ютера.
  2. Вивчити алгоритм, за яким працює штатна програма-перепаковщік 264-avi і створити таку ж програму, яка б виконувала ті ж операції, але вже не над одним, а над цілою групою файлів, причому одним натисненням.

Перше завдання, на перший погляд, може здатися дуже просте: потрібно просто підключити HDD до комп’ютера і відкрити розділи в провіднику. Однак тут є свої підводні камені. Дана стаття присвячена саме першій задачі.

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

Для дослідження використовував безліч програмних інструментів: дисковий редактор (він же і файловий бінарний редактор) 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, які є ключами до необхідних відеозаписів.

Читайте також  Як технології маніпулюють вашим розумом: погляд ілюзіоніста і експерта з етики дизайну Google

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

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

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

Така послідовність з пропусками припадала на nvr файли, відповідні відеозаписів, які DVR записував одночасно з двох і більше каналів. Тобто, наприклад, якщо послідовність«435, 436, 438, 439, 442,…» відноситься до відеозапису з одного каналу, то пропущені значення (437, 440, 441) будуть ставитися до відеозапису з іншого каналу, яка здійснювалась в той же момент часу. У цьому я сам переконався, переглянувши і порівнявши відповідні nvr файли, спираючись на їх ім’я. Не залишається сумнівів, що наведені вище числа утворюють номери якихось частин, що мають відношення до відеозаписів. Залишається тільки розгадати зв’язок між цими числами і координатами дискового простору, на якому розміщені дані.

Також, належало з’ясувати, які саме дані діляться на вищесказані нумеровані сегменти? Перше припущення – даними є потоки аудіо і відео, які у контейнері 264 представлені короткими блоками, причому, як було сказано, блоки відеопотоку мають різний розмір. При цьому DVR на етапі отримання відеозапису на зовнішній носій збирає ці потоки і упаковує в контейнер 264. Друге припущення – потоки аудіо і відео DVR упаковує в контейнер 264 до початку і під час відеозахоплення. І при цьому на HDD записуються вже сформовані дані файлу .264, який вийшов в результаті його вилучення на зовнішній носій. Досліджуючи простір HDD десь в середині другого розділу, поряд з байтами потоків аудіо і відео і їх заголовками того ж виду, що і в контейнері 264, мені також траплялися і заголовки самого контейнера: MDVR96NT_2_R. Після даного заголовка було безліч байтів нулів. В цілому, дослідження показало, що має місце другий варіант з двох вищенаведених. Тому, для отримання потрібного файлу .264, найімовірніше, потрібно просто з’єднати разом всі сегменти, номери яких містяться у відповідному файлі nvr.

Читайте також  Дизайн-процес, дослідження і пошук роботи

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

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

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

Я провів ще один додатковий цікавий експеримент, щоб остаточно розвіяти всі сумніви. Він описаний нижче.

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

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

Щоб переконатися в справедливості формули, обчислимо позицію першого сегмента якого-небудь іншого довільного файлу .264, керуючись відповідним файлом nvr. Звертаючи увагу на дату і час в імені файлу, порівняємо їх з першими байтами в заголовку .264, що знаходиться на обчислення секторі. Байти, що кодують окремо число, місяць, рік, години, хвилини, секунди, відповідають часовим даними в назві файлу. Отже, «потрапили в точку»! Підрахуємо у файлі nvr, відповідному извлеченному заздалегідь файлу .264, кількість сегментів cs. Взагалі, їх число дорівнює cs = sf/32-1, де sf – розмір файлу nvr. Якщо файл .264 складається з cs сегментів, то його розмір повинен бути дорівнює cs*65536+4 (число сегментів, помножена на розмір сегмента в байтах, плюс 4 тих самих байта нулів). І це дійсно так!

Читайте також  Поле завантаження файлів, яке ми заслужили

Все-таки, спробуємо дослідити другий розділ. Як вже зазначалося раніше, щось схоже на суперблок знаходиться в першому секторі розділу (16016805). А його точна копія була виявлена сім’ю секторами нижче (16016812). Очевидно, ненульова основна інформація знаходиться у першому секторі суперблоку. Його вигляд в дисковому редакторі наведено на малюнку нижче.

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

Тобто, другий розділ можна назвати урізаним і трохи видозміненим розділом EXT2. У ньому є суперблок, його копія, бітова карта. Але відсутні т. н. інформаційні вузли, відповідні файловим записів. Розділ містить дані файлів .264 (аудіо і відео потоки), але інформаційні вузли (скажімо так) для цих даних розміщені в nvr файлах першому розділі. Може бути, існує більш грамотна формулювання? Але мені це вже не настільки важливо.

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

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

Бібліотеки потрібні такі.

#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) {
 return CreateFile ( filename, // Open Two.txt.
 GENERIC_WRITE, // Open for writing
 0, // Do not share
 NULL, // No security
 OPEN_ALWAYS, // Open or create
 FILE_ATTRIBUTE_NORMAL, // Normal file
 NULL); // No template file 
}

У функцію копіювання укладена формула лінійної залежності, яка фігурувала в теорії вище.

void copy(HANDLE device, file HANDLE, 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("nnFOLDER: %snn",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%snt%i Blocksnn",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.

Степан Лютий

Обожнюю технології в сучасному світі. Хоча частенько і замислююся над тим, як далеко вони нас заведуть. Не те, щоб я прям і знаюся на ядрах, пікселях, коллайдерах і інших парсеках. Просто приходжу в захват від того, що може в творчому пориві вигадати людський розум.

You may also like...

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *