Відновлення відеофайлів з камери Canon LEGRIA HF G30

Datex > Статті > Відновлення відеофайлів з камери Canon LEGRIA HF G30

Відновлення відеофайлів з камери Canon LEGRIA HF G30

Звернувся до нас клієнт з банальної, здавалося б, проблемою - видалив з карти пам'яті відзнятий відеокамерою Canon LEGRIA матеріал. Більшість відразу скаже: «так скористайся будь-якою програмою по відновленню видалених файлів, в чому проблема?». А проблема, виявляється, є, і суттєва. Всі сучасні камери, з якими ми стикалися - створюють на носії файли в фрагментованому вигляді. Це стосується всіх камер, які зберігали відео в форматі Apple QuickTime (mov / mp4). Наочні приклади - дзеркальні фотокамери Canon, екшн-камери GoPro та їх безіменні аналоги, автомобільні відеореєстратори.
Коротка ремарка по вмісту файлів в зазначеному форматі: файл має складну вкладену структуру, кожен елемент даних називається атомом. Більш детальну інформацію можна знайти за посиланням, тут залишу лише пояснювальну картинку:

Продовжимо. Після банального видалення файлів втрачається найважливіше - інформація про розташування фрагментів (кластерний ланцюжок) файлів. Відразу уточнюю - ситуація, про яку я розповідаю, вірна для файлової системи FAT32. Для NTFS або ExFAT ситуація може бути іншою. У випадку з FAT32 і видаленими фрагментованими файлами існує всього два методи їх відновлення:

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

Ми вже неодноразово працювали з різними відеоформатами, і знаємо, що далеко не кожен потік відео / аудіо даних можна відновити і відтворити без супровідних службових метаданих. Наприклад, простий формат MPEG-2 - є потоковим, і для його відтворення не потрібні ніякі додаткові службові дані - просто сирий потік даних, вирівняний по межі фрейма. Такий потік можна відновити першим методом і не витрачати час на службові дані. Також першим методом можна відновлювати сирий відеопотік без службових даних, навіть якщо він був в Apple QuickTime контейнері (mov / mp4), за умови використання певного відеокодека. Однак дана відеокамера створює файли з відеопотоком, який не залишає шансів на відновлення першим методом:

В такому форматі немає ніяких «зачіпок», щоб відокремити фрейми з відео і аудіо даними друг від друга. Вони йдуть суцільним потоком, а інформація про те, де знаходяться межі фреймів - збережена в службових атомах trak. Ці метадані записуються камерою у вигляді окремого фрагмента в віддаленому від основного потоку даних місці носія. Причому, як показали наші дослідження, кожна камера записує на носій фрагменти файла неоднаково, скрізь використовується різний алгоритм їх розміщення. Десь цей алгоритм простий, і його можна відтворити, отримавши на виході повністю дефрагментовані та робочі відеофайли (дзеркалки Canon). У випадку з піддослідною відеокамерою - ніякої особливої закономірності немає - камера просто пише метадані в одну частину носія, а відеопотік - в іншу. При цьому метадані можуть додатково фрагментуватися. Загалом, все погано, і завдання на перший погляд виглядає нездійсненним.
Однак, вивчивши в HEX-редакторі кілька прикладів відеофайлу з піддослідної камери, був придуманий алгоритм збірки «фрагментів» за маркерами з вмісту файлу. Для вирішення завдання необхідно повністю проаналізувати приклад файлу, зрозуміти які атоми використовуються, яку інформацію з них ми можемо використовувати для прив'язки, і як потім, знаходячи вміст цих атомів на носії, з'єднати знайдені фрагменти в єдине ціле. Для розуміння первинної структури використовуємо MP4 Explorer:

Структура стандартна. Атом mvhd з часом створення файлу виявився для нас дуже важливим - за часом створення можна пов'язати знайдений на диску фрагмент з атомами trak з початком файлу, фрагментом ftyp. Глянемо на початок файлу в HEX вигляді:

Тут в службовому атомі CNTH-> CNDA знаходиться картинка-передперегляд файлу, в якій дуже вдало для нас є дата створення файлу в текстовому вигляді. Ця інформація стане в нагоді далі. Як виявилося, камера при формуванні метаданих резервує фіксоване місце під цю картинку, а також під коментар користувача камери, який можна помістити в службовий атом udta. Ну а найголовніше, що атом з безпосередньо медіапотоком, mdat - записується камерою найчастіше нефрагментованим. І знову дуже вдало - в цьому атомі є за що зачепитися для пошуку відповідного йому атома mhvd і ftyp.

Приступаємо до створення інструменту для відновлення - створюємо новий проект в С ++ Builder:

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

По ходу написання інструменту визначаємо алгоритми валідації цілісності знайдених фрагментів, як виявилося - це реально. Знайшлись заголовки файлів і секції mdat з медіапотоком:

Після цього обробляємо масив знайдених даних, аналізуємо ті атоми, які можемо, і навіть перевіряємо на нефрагментованість знайдені контейнери.

Непогано, частина метаданих знайшлася єдиним фрагментом, але є й фрагментовані. З ними будемо розбиратися пізніше. Далі пов'язуємо знайдені фрагменти з метаданими з відповідними їм атомами mdat і зберігаємо отримані відеофайли, попутно перевіряючи їх вміст окремою функцією-валідатором структури атомів:

FILE 043A8B6B.mov check ok!

FILE 01010D52.mov check ok!

FILE 019E9DAD.mov check ok!

FILE 017FC7C4.mov check ok!

FILE 00BFA3DE.mov check ok!

Перевіримо відновлені файли:

Все програється! Ура, але ще залишилося близько 20% невідновлених файлів, метадані яких виявилися фрагментовані. Пишемо для них окремий складальник, який зв'яже знайдені фрагменти початку і середини метаданих, спираючись на дату створення файлу:

    У підсумку програма зібрала нам ще частину робочих файлів.
    На даному етапі залишилося всього 25 фрагментів з метаданими, які не вдалося зібрати в цілісні файли. Зберігаємо всі фрагменти, що залишились, у вигляді окремих файлів, та з'єднуємо ці фрагменти вручну, спираючись на знання про те, що де має лежати всередині файлу. Як виявилося, метадані цих 25 файлів були сильно фрагментовані - від 3 до 5 фрагментів. Однак через кілька годин копіткої роботи всі до єдиного файли вдалося зібрати.
    Як результат, ми отримали рівно 244 робочих файлів, що є 100% успішним відновленням (трохи вище в тексті можна побачити кількість знайдених заголовків файлів - їх було 244).
    Клієнт залишився дуже задоволений, тому що весілля перезняти вже неможливо ...

Відправити відповідь

Залиште перший коментар