Сначала увидеть, что в видео сломано, потом восстановить

Что эта страница на самом деле проверяет

Внутри MP4 или MOV каждый кадр H.264 или HEVC хранится цепочкой: число-длина, затем столько же байтов данных изображения, затем следующая длина — и так, стык в стык, пока данные кадра не закончатся. Цепочка обязана попасть ровно в конец. Если длина равна нулю или указывает за границу данных, байты этого кадра — не то, чем файл их объявляет.

Именно это страница и измеряет, кадр за кадром, по всему файлу. Поэтому она может сказать, **где** повреждение, а не только «видео не играет»: у каждого битого кадра есть позиция и метка времени, так что повреждение можно нарисовать на шкале.

Если вы когда-нибудь прогоняли битое видео через ffmpeg и видели, как проносится `Invalid NAL unit size (0 > 1241)`, — это сообщение о том же самом. Плееры обычно отвечают на это подвисанием, пропуском или мазнёй из блоков: с байтами, которых нет, больше ничего и не сделать.

Этой проверке не нужен видеодекодер — поэтому она работает и с файлами, которые ваш браузер вообще не может воспроизвести. Она читает байты, а не картинки.

Два разных вида поломки — и выглядят они по-разному

**Кадры с испорченными данными.** Что-то записало неверные байты: прерванное копирование на флешку, умирающая карта памяти, синхронизация, оборвавшаяся на середине. Длина файла и индекс целы, видео открывается нормально, но отдельные кадры внутри непригодны. На шкале это отметки, разбросанные там, где произошло повреждение.

**Видео, оборвавшееся на середине.** Загрузка или передача остановилась раньше времени. Заголовок по-прежнему заявляет исходную длину, поэтому плеер показывает полную полосу прокрутки, но данные изображения просто заканчиваются на середине. Страница обнаруживает это, сравнивая заявленную длину с последним кадром, до которого реально удаётся дойти, — на шкале это один серый блок в конце.

Различать их стоит потому, что ожидания у них разные. Разбросанные повреждения обычно стоят вам секунды здесь и секунды там. А файл, обрезанный на 40 %, лишён целых 60 % видео, и никакой инструмент не придумает то, что никогда не было записано.

Почему восстановленный файл короче

Кадры видео не независимы. Ключевой кадр самодостаточен, а следующие за ним хранятся как отличия от него — поэтому если данные ключевого кадра испорчены, все опирающиеся на него кадры тоже непригодны, хотя их собственные байты в полном порядке. Вот почему файл с десятью битыми кадрами может потерять существенно больше десяти.

Восстановление оставляет только те кадры, которые действительно декодируются, и смыкает пропуски, чтобы результат играл от начала до конца, а не замирал на месте повреждения. Плата за это — результат короче исходного ровно на столько, сколько было отброшено. Страница сообщает это число до того, как вы решите, и повторяет его на результате.

Ничего не перекодируется. Уцелевшие кадры копируются побайтово, поэтому качество того, что осталось, — в точности исходное, а вся операция занимает секунды, а не минуты.

**Звук сохраняется и остаётся синхронным.** Смыкание пропусков означает, что картинка больше не совпадает со звуком исходной длины, поэтому звук обрезается ровно по тем же границам: каждый сохранённый отрезок изображения несёт свой отрезок звука, сдвинутый на ту же величину. Внутри отрезка они сцеплены жёстко; расходиться звук может только на стыках, и не более чем на половину звукового пакета — около десяти миллисекунд. Это на порядок ниже того, что кто-либо воспримет как рассинхрон.

Чего эта страница не может

**Файл, который вообще не открывается, здесь недосягаем.** В каждом MP4 есть индекс с описанием того, где лежит каждый кадр. Если этот индекс повреждён или отсутствует — обычное дело, когда запись остановилась без корректного завершения, — идти не по чему, и страница прямо об этом скажет, а не будет крутить индикатор. Такие файлы спасает исходник или инструмент, восстанавливающий индекс перебором границ кадров.

**Повреждения звука не обнаруживаются.** Звуковая дорожка переносится и держится в синхроне, но её никогда не *проверяют*: чтобы найти битый звуковой пакет, нужно прогнать его через декодер — совсем другая и куда более медленная работа, чем чтение префиксов длины. Видео с идеальной картинкой и испорченным звуком выйдет из этой проверки «чистым».

**Только H.264 и HEVC.** Именно они хранят кадры с префиксами длины — то, что читает проверка. MJPEG, MPEG-4 Part 2 и другие раскладывают кадры иначе: измеренные этой линейкой, они все выглядели бы повреждёнными, поэтому страница отказывается.

Частые вопросы