AVInaptic позволяет открыть видеофайл, получить подробный технический отчёт о контейнере, видеопотоке и аудиодорожках, выполнить углублённый анализ MPEG-4 ASP или H.264 с DRF-статистикой и графиками, извлечь отдельные дорожки, проверить синхронизацию и параметры AVI, а также проанализировать и привести в порядок субтитры SRT. Программа полезна, когда нужно понять, почему конкретный файл воспроизводится не так, как ожидается, чем отличаются два варианта кодирования или какие параметры следует сохранить перед ремультиплексированием.

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

Сильнее всего программа раскрывается при разборе AVI, Matroska, MP4/MOV и материалов с MPEG-4 ASP либо AVC. Она распознаёт также ASF/WMV, OGG, OGM и FLV, но объём выводимых полей зависит от контейнера и кодека. Отдельная группа функций относится к SRT: можно проверить структуру субтитров, найти проблемную нумерацию и временные метки, удалить пустые записи и теги, переразбить длинные строки, ограничить число строк и сохранить исправленный файл как новый.

Что именно показывает AVInaptic

AVInaptic не пытается свести медиафайл к одной строке вида H.264, 1920×1080, AAC. Его отчёт устроен так, чтобы можно было отделить свойства контейнера от свойств закодированных потоков. Это важно: контейнер может сообщать одну длительность или один аспект, а сам битстрим — давать дополнительную информацию, которая объясняет расхождение. Поэтому в отчёте встречаются отдельные значения для container и bitstream, а для некоторых аудиоформатов — ещё и сведения, полученные при последовательном разборе кадров.

Для типичного видео в начале отчёта видны имя, дата, размер, распознанный тип файла, длительность, контейнер и количество дорожек. Далее перечисляются дорожки: видео, аудио, субтитры, а у Matroska также могут быть вложения. После этого идёт блок Relevant data с разрешением и сводными показателями, затем подробности каждой дорожки. Если видео кодировано MPEG-4 ASP или H.264, ниже появляются параметры самого видеобитстрима — профиль, особенности кодирования, данные энкодера и, после полной проверки, распределение кадров и DRF.

Именно такое разделение делает отчёт удобным для диагностики. Если проигрыватель жалуется на файл, первым делом можно проверить не только название кодека, но и FourCC, профиль, уровень, QPel, GMC, режим чересстрочного кодирования, матрицу квантования, packed bitstream, частоту кадров и соотношения сторон. Если проблема связана с рассинхронизацией, полезны задержки дорожек, сведения об interleave/preload в AVI, число null frames и максимальная разница аудио/видео.

Быстрый отчёт и полное сканирование

При обычном открытии файла AVInaptic сначала работает в быстром режиме. Он считывает структуру контейнера и доступные заголовки, поэтому результат появляется заметно раньше, чем при покадровом анализе. Такой отчёт достаточен, когда нужно узнать кодек, разрешение, частоту кадров, количество дорожек, язык, тип аудио, идентификатор потока или общую длительность.

Если нужны сведения, которые нельзя надёжно получить из заголовков, используется команда Misc → Full analysis/DRF Graph или соответствующая кнопка с графиком. Полный проход имеет смысл прежде всего для MPEG-4 ASP и AVC: программа последовательно анализирует битстрим, считает кадры, размеры потоков, статистику DRF и строит данные для графика. На длинном файле операция может занять время, потому что речь идёт уже не о чтении нескольких килобайт заголовка, а о просмотре большого объёма медиаданных.

Полный отчёт следует сохранять только после завершения анализа: AVInaptic записывает в текстовый файл именно те сведения, которые в этот момент показаны в главном окне. Если сначала сохранить быстрый отчёт, а затем выполнить углублённое сканирование, тексты будут различаться. Это нормальное поведение, а не потеря данных.

Почему расширение файла не является главным признаком

AVInaptic старается распознавать контейнер по содержимому, а не только по суффиксу имени. Такой подход особенно полезен для AVI и MP4-подобных файлов, которые иногда получают нестандартные расширения, а также для случаев, когда файл просто переименовали. В строке типа файла и в описании контейнера нужно ориентироваться на результат анализа, а не на предположение, сделанное по имени.

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

Интерфейс и основной порядок работы

Главное окно AVInaptic предельно компактно: сверху расположено меню File, Copy, Demux, Misc и Help, под ним — ряд кнопок для наиболее частых операций, а почти вся оставшаяся площадь отдана текстовому отчёту. Цветом выделяются заголовки разделов, названия полей и значения. Такой интерфейс ориентирован не на предпросмотр видео, а на чтение диагностических данных.

Открыть файл можно через File → Open, кнопкой с пиктограммой папки или перетаскиванием поддерживаемого файла на программу. После выбора AVInaptic сразу формирует быстрый отчёт. Если окно заполнено большим объёмом текста, используется обычная прокрутка; в технических материалах удобнее сначала найти секцию по её заголовку, а затем уже разбирать отдельные строки.

Меню Copy предназначено для переноса отчёта в буфер обмена в поддерживаемом программой представлении. Это удобно, когда нужно приложить параметры файла к сообщению, заявке на диагностику или внутренней документации без промежуточного сохранения. Для долговременного хранения лучше использовать команду сохранения отчёта: она создаёт отдельный текстовый результат, который можно сопоставлять с другими файлами.

Безопасность при открытии и изменении файлов

Само открытие медиафайла выполняется для чтения: анализ не меняет видео. Изменение возникает только в тех операциях, где пользователь явно просит AVInaptic поправить AVI — например, выставить задержку аудиодорожки или изменить FourCC — и подтверждает действие. Это принципиально отличает диагностический просмотр от команд редактирования заголовка.

Перед изменением AVI всё равно разумно сохранить копию. Хотя операция с задержкой или FourCC не перекодирует изображение и занимает мало времени, она затрагивает служебные поля контейнера. Ошибочное значение FourCC способно ухудшить совместимость, а неверно выбранный знак задержки — увеличить рассинхронизацию вместо её исправления.

С SRT применяется ещё более осторожная схема. Когда запускается редактирование субтитров, записи импортируются во внутренние таблицы, а исходный файл остаётся нетронутым. Чтобы получить результат, нужно явно экспортировать текущие записи в новый SRT. Если закрыть окно редактирования без экспорта, промежуточные изменения будут потеряны, а исходник сохранится в прежнем состоянии.

Как сохранять отчёты для сравнения

Если задача — сравнить два кодирования одного источника, отчёты лучше получать одинаковым способом. Оба файла сначала анализируют быстро либо оба — полностью. Затем сохраняют результаты под понятными именами, где отражены вариант кодирования и режим анализа. Так проще сопоставлять не только разрешение и средний битрейт, но и число кадров, размер видеопотока, структуру I/P/B-кадров и статистику DRF.

При сравнении нельзя делать вывод по одной строке Average DRF. Для разных кодеков шкала квантования устроена по-разному, а даже внутри H.264 одинаковый средний DRF не означает одинаковое субъективное качество. Нужно учитывать профиль, B-кадры, reference frames, настройки психовизуальной оптимизации, разрешение, зерно исходника и распределение DRF по типам кадров.

Как читать начало технического отчёта

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

Далее AVInaptic показывает Magic или аналогичный блок распознавания. Здесь может быть указано семейство формата, которое удалось определить по сигнатуре данных. Если расширение говорит .avi, а распознавание не подтверждает RIFF/AVI, есть основание проверять повреждение, ошибочное переименование или необычный контейнер.

Секция общей информации описывает длительность, тип контейнера, количество потоков и их типы. У Matroska здесь могут появляться Muxing library и Writing application. Эти поля полезны при поиске источника особенностей контейнера: они показывают, каким инструментом или библиотекой файл был мультиплексирован, но сами по себе не доказывают качество изображения.

Количество и типы дорожек

Каждая дорожка в контейнере учитывается отдельно. Для Matroska типичная запись сообщает номер потока и его Codec ID: например, видеопоток AVC, аудио AAC или AC-3, текстовые субтитры. Если у файла несколько аудиодорожек, отчёт помогает не перепутать их перед извлечением и увидеть, чем они различаются по кодеку, частоте дискретизации и каналам.

Отдельно нужно различать число потоков и число аудиопотоков. Первое включает видео, звук, субтитры и другие элементы, которые AVInaptic распознал как дорожки; второе относится только к аудио. Для сложного MKV это простой способ быстро понять структуру без запуска проигрывателя.

Если контейнер содержит вложения, демультиплексор AVInaptic может извлечь их вместе с обычными медиапотоками. Это характерно прежде всего для Matroska, где в качестве attachments могут храниться шрифты и другие вспомогательные файлы. Извлечение не означает декодирование: программа просто сохраняет выбранный объект отдельно.

Длительность: почему значения могут расходиться

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

Практический интерес представляет систематическое расхождение. Если видеодорожка заметно короче аудио, а проигрыватель к концу уходит из синхронизации, нужно проверять частоту кадров, пропуски кадров, null frames и временную разметку. Если же длительности почти совпадают, но звук смещён на постоянную величину от начала до конца, вероятнее проблема в статическом delay.

Разрешение, FAR, PAR и DAR

AVInaptic явно разделяет три понятия, которые часто смешивают. Frame Aspect Ratio (FAR) — отношение ширины сохранённого кадра к высоте. Pixel Aspect Ratio (PAR) — отношение ширины пикселя к его высоте. Display Aspect Ratio (DAR) — пропорция изображения при правильном отображении. Между ними действует простое соотношение: DAR = FAR × PAR.

Для современного видео с квадратными пикселями PAR равен 1:1, поэтому DAR совпадает с геометрией кадра. Но у материалов стандартного телевидения и некоторых старых кодирований пиксели могут быть прямоугольными. Тогда файл 720×576 вовсе не обязан отображаться в пропорции 5:4; метаданные или параметры битстрима могут задавать 4:3 либо 16:9.

В отчёте полезно смотреть все три строки вместе. Если программа показывает разрешение 720×576, FAR 5:4, PAR не 1:1 и DAR 4:3, это внутренне согласованный набор. Если же проигрыватель растягивает видео иначе, проблема может быть не в самом размере кадра, а в том, какую информацию об аспекте он предпочитает: контейнерную или закодированную в потоке.

Когда значение PAR нельзя считать истиной в последней инстанции

AVInaptic анализирует то, что записано в файле. Если исходные метаданные ошибочны, программа честно покажет ошибочное значение как свойство файла. Это особенно важно при оцифровке SD-видео: фактическое производственное соглашение о пиксельном аспекте может не совпадать с тем, что записал конкретный захватчик или контейнер.

Поэтому при спорном PAR нужно сопоставить геометрию известного тестового объекта, стандарт источника и значения из нескольких анализаторов. AVInaptic полезен именно тем, что показывает FAR/PAR/DAR отдельно, но он не может восстановить намерение оператора, если заголовки исходника содержат неверную сигнализацию.

Частота кадров, число кадров и ключевые кадры

Строка Framerate показывает частоту кадров, которую AVInaptic получил из структуры файла или битстрима. В типичных материалах встречаются 23.976, 24, 25, 29.97, 30 и другие значения. Для субтитров эта информация особенно важна, когда временная разметка была подготовлена под другой темп видео: постоянное нарастающее расхождение иногда связано именно с преобразованием частоты кадров.

После более глубокого анализа в видеосекции могут присутствовать Total frames, Key frames, минимальный, максимальный и средний интервал между ключевыми кадрами. Эти показатели позволяют оценить структуру GOP. Частые ключевые кадры повышают удобство произвольной навигации, но обычно требуют больше битов; редкие — экономят часть объёма, зато увеличивают расстояние до точки независимого декодирования.

Список позиций key frames полезен, когда нужно проверить необычный скачок размера кадра или сопоставить проблемный момент с графиком DRF. Однако AVInaptic не является видеоредактором: из списка ключевых кадров нельзя сразу вырезать сцену. Он даёт координаты и статистику, а само редактирование выполняется другим инструментом.

Null frames и N-VOPs

Для AVI программа умеет учитывать null frames — фиктивные кадры уровня контейнера. Они не несут обычного закодированного изображения, но занимают временную позицию. Если проигрыватель или последующий инструмент игнорирует такие позиции, видео может постепенно уйти вперёд относительно звука. Поэтому ненулевое значение важно при расследовании A/V sync.

В MPEG-4 ASP встречается близкое по практическому эффекту понятие N-VOP. Это уже элемент видеобитстрима, а не тот же самый контейнерный механизм. В некоторых рабочих цепочках, чувствительных к временным меткам, полезно убедиться, что и null frames, и N-VOPs отсутствуют. AVInaptic способен вывести эти сведения в расширенном отчёте для подходящего потока.

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

Параметры MPEG-4 ASP в отчёте

AVInaptic особенно подробно разбирает MPEG-4 Part 2 Advanced Simple Profile — семейство, с которым обычно ассоциируются XviD, DivX и некоторые реализации Lavc. В отчёте появляется отдельный блок о MPEG-4-кодировании, где можно увидеть идентифицирующие данные, QPel, GMC, признак interlaced, информацию об aspect ratio, тип квантования и другие доступные параметры.

Эта группа полей важна при работе со старой техникой и архивными AVI. Два файла с одинаковым FourCC и одинаковым разрешением могут различаться по функциям битстрима, которые поддерживает не каждый аппаратный декодер. AVInaptic помогает обнаружить такую причину без пробного перекодирования всех вариантов подряд.

QPel

QPel, или Quarter Pixel Motion Compensation, обозначает использование четвертьпиксельной точности при компенсации движения. Для анализа совместимости сам факт включения важнее попыток оценить качество: декодер должен уметь корректно обработать соответствующий синтаксис MPEG-4 ASP. Если устройство воспроизводит один XviD-файл, но отказывается от другого, строка QPel — одна из первых, которые стоит сопоставить.

AVInaptic не выключает QPel переключателем в отчёте. Это характеристика уже закодированного видеопотока. Если целевой декодер её не поддерживает, решение обычно требует перекодирования с совместимыми настройками. Изменение FourCC здесь бесполезно: FourCC меняет идентификатор в контейнере, но не переписывает структуру самого битстрима.

GMC

GMC означает Global Motion Compensation. Для MPEG-4 ASP этот механизм может быть реализован по-разному, а аппаратная совместимость исторически зависела от конкретного декодера и числа warping points. AVInaptic фиксирует наличие GMC, позволяя объяснить ситуацию, когда программный проигрыватель справляется с файлом, а специализированное устройство — нет.

Здесь действует тот же принцип, что и для QPel: поле отчёта является диагностическим. Если требуется максимальная совместимость с ограниченным декодером, поток перекодируют без неподдерживаемой возможности. Попытка починить GMC заменой расширения AVI или FourCC не изменит закодированные VOP и потому не решит проблему.

Interlaced и фактическая чересстрочность

Признак Interlaced в MPEG-4 ASP говорит о режиме кодирования, а не автоматически о том, что исходная съёмка действительно содержит два временно разнесённых поля. Прогрессивный материал тоже можно было по ошибке закодировать с включённым interlaced-режимом. Поэтому значение нужно трактовать как свойство битстрима, а не как визуальный диагноз кадра.

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

Матрицы квантования

В MPEG-4 ASP квантование может использовать матрицу H.263, стандартные MPEG-матрицы или пользовательские матрицы. AVInaptic сообщает тип, который обнаружен в потоке. Пользовательская матрица влияет на то, как распределяется точность между пространственными частотами, поэтому два файла с одинаковым средним DRF не обязательно будут вести себя одинаково.

Для старых аппаратных декодеров важна ещё и поддержка самой матрицы. Если устройство рассчитано только на H.263, поток с MPEG или custom matrix может декодироваться неправильно либо не декодироваться вовсе. В этом случае отчёт AVInaptic помогает отличить проблему битстрима от проблемы контейнера.

Packed bitstream

Packed bitstream — способ упаковки MPEG-4 ASP, при котором в одном контейнерном кадре могут оказаться данные более чем одного VOP. Он появился как практическое решение особенностей B-кадров в AVI, но некоторые декодеры обрабатывали такую схему плохо. AVInaptic определяет этот признак, поэтому его стоит смотреть при рывках или ошибках воспроизведения старых XviD/DivX.

Важное отличие от QPel и GMC состоит в том, что packed bitstream во многих случаях можно преобразовать в unpacked без полного перекодирования видеопотока специализированным инструментом. Сам AVInaptic предназначен для определения признака, а не для такого преобразования. Это позволяет выбрать менее разрушительный способ исправления, когда проблема действительно связана с упаковкой VOP.

Анализ H.264/AVC

Для H.264 AVInaptic читает не только Codec ID контейнера. В блоке о видеобитстриме отображаются данные Sequence Parameter Set и Picture Parameter Set, профиль, число reference frames, аспект, формат цветности, тип энтропийного кодирования, признаки weighted prediction и 8×8 DCT, если соответствующая информация доступна.

Кроме формальных параметров стандарта программа может извлекать текстовые user data, оставленные энкодером. Для x264 это особенно полезно: в отчётах встречаются строки с ядром энкодера и набором параметров — CABAC, ref, deblock, analyse, me, subme, psy, trellis, 8x8dct, keyint, scenecut, bframes, rc, crf, qcomp, vbv и другими. Такой блок позволяет понять, как был настроен конкретный поток, если энкодер сохранил сведения внутри файла.

Наличие параметра в user data не означает, что AVInaptic вычислил его по изображению. Это информация, встроенная энкодером. Поэтому для файлов, созданных другими кодировщиками или с отключённой записью служебных строк, список может быть короче. Отсутствие строки crf, например, не доказывает, что режим CRF не применялся.

Profile и Level

Поля H.264 Profile и Level описывают набор допустимых инструментов и верхние ограничения потока. Для совместимости с аппаратным декодером это значительно информативнее, чем одна надпись H.264. Устройство может поддерживать AVC в целом, но ограничиваться определённым профилем, уровнем, разрешением или числом reference frames.

Если проблемный файл имеет более высокий Level, чем допускает устройство, нужно выяснить, действительно ли поток использует превышающие ограничения параметры. Иногда уровень лишь сигнализируется консервативно, но AVInaptic не является автоматическим валидатором всех требований H.264. Его данные служат отправной точкой: профиль и level сопоставляют со спецификацией декодера и остальными полями отчёта.

Reference frames

Num ref frames показывает число опорных кадров, заявленное в параметрах последовательности. Большое число reference frames повышает требования к памяти декодера и входит в ограничения уровня H.264. Для старых медиаплееров это могло быть причиной отказа даже при подходящих разрешении и битрейте.

При сравнении двух кодирований не следует делать вывод больше ref — всегда лучше. Эффективность зависит от содержимого и режима энкодера, а современный кодек умеет выбирать полезные ссылки. Для AVInaptic это прежде всего технический параметр, который помогает воспроизвести настройки и проверить совместимость.

CABAC и CAVLC

В отчёте может указываться Entropy coding type. CABAC обеспечивает более эффективное энтропийное кодирование, но требует от декодера поддержки соответствующего профиля и больших вычислительных затрат, чем CAVLC. Если аппаратное устройство рассчитано на ограниченный профиль, это поле помогает объяснить разницу между двумя AVC-файлами.

Для обычного программного воспроизведения на современном компьютере само наличие CABAC редко является проблемой. Значение становится действительно полезным в контексте целевого декодера, а не как абстрактная оценка хорошо/плохо.

Weighted prediction и 8x8dct

AVInaptic способен показать варианты weighted prediction для P- и B-срезов, а также использование 8×8 DCT. Эти поля характеризуют инструменты компрессии H.264. Они полезны при сравнении параметров разных энкодов и при проверке ограничений профиля, но не должны рассматриваться изолированно от всего потока.

При воспроизведении на программных декодерах поддержка этих функций обычно определяется самим профилем H.264. Если же файл готовится для конкретного аппаратного проигрывателя, нужно смотреть требования устройства целиком: разрешение, level, reference frames, VBV и другие ограничения могут оказаться важнее одного переключателя.

Строки x264 и практическая польза user data

Когда x264 записал строку параметров, AVInaptic разворачивает её в читаемый список. Это удобно при реконструкции рецепта кодирования. Например, можно увидеть ref, me, subme, trellis, bframes, keyint, scenecut, rc, crf, vbv_maxrate и vbv_bufsize. Для технического архива такой отчёт часто ценнее имени исходного пресета, которое могло не сохраниться.

Но восстановить командную строку побайтно из этих сведений нельзя. Некоторые параметры могли быть заданы по умолчанию, часть могла не попасть в user data, а интерфейс энкодера мог преобразовать настройки перед запуском. Правильнее считать блок x264 снимком существенных параметров, достаточным для анализа, но не гарантированным файлом проекта.

DRF: что измеряет AVInaptic

DRF в терминологии AVInaptic связан с параметром квантования: чем выше квантование, тем сильнее округляются преобразованные коэффициенты и тем больше потенциальная потеря деталей. Для MPEG-4 ASP диапазон квантайзера существенно уже, чем для AVC, поэтому численные значения между этими двумя семействами нельзя сравнивать напрямую.

В H.264 шкала квантования обычно рассматривается в диапазоне 0–51, а в MPEG-4 ASP — 1–31. Даже внутри одного кодека средний DRF не является универсальной метрикой визуального качества. Сложная зернистая сцена и статичный мультфильм могут требовать совершенно разного количества битов при одинаковом значении квантования.

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

Average DRF

Average DRF — среднее значение по анализируемым кадрам или срезам в пределах того, как AVInaptic трактует соответствующий битстрим. Оно удобно для первого сравнения двух файлов, созданных одним кодеком из одного и того же источника. Если условия различаются, число легко вводит в заблуждение.

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

Standard deviation и weighted mean

Стандартное отклонение показывает, насколько значения DRF разбросаны относительно среднего. Небольшой разброс характерен для более равномерного квантования, большой — для материала или rate control, где степень квантования заметно меняется от сцены к сцене. Это не самостоятельный показатель качества, а характеристика поведения кодирования.

В сводном блоке AVInaptic встречается и взвешенный показатель отклонения. Он помогает описывать вариативность с учётом внутреннего распределения кадров. Практически его удобнее использовать для сопоставления двух очень похожих энкодов, а не для установления абстрактного порога хорошего видео.

Распределение DRF

Полный отчёт может перечислять, сколько кадров или срезов пришлось на каждое значение DRF и какой процент это составляет. Такая гистограмма полезнее одного среднего при поиске хвоста высоких значений. Если среднее выглядит нормально, но заметная доля сложных сцен ушла в гораздо более высокие DRF, именно эти участки стоит просмотреть визуально.

Раздельные строки для I-, P- и B-срезов позволяют увидеть естественную асимметрию: разные типы кадров кодируются при разных условиях. Поэтому сравнивать максимальный DRF B-кадров с минимальным DRF I-кадров как две равноправные величины некорректно. Гораздо информативнее сравнивать одинаковые типы между двумя версиями одного материала.

График DRF

Окно DRF graph показывает распределение квантования по времени и связывает его с нижним графиком размеров кадров. В интерфейсе присутствуют поля DRF range, Frame size range, фильтр Frame type, навигация Prev/Next, переход Goto, выбор содержимого нижнего графика и параметр Avg int.

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

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

График частичного среднего битрейта

Помимо DRF программа умеет строить график partial average bitrate. Это не мгновенный битрейт каждого кадра. В момент времени t значение рассчитывается как средний битрейт от начала файла до этого момента. Поэтому кривая постепенно стабилизируется и показывает, как накопленный средний размер потока приближается к итоговому значению.

Такой график может быть полезен при анализе rate control. Если кодирование нацелено на определённый средний битрейт, кривая показывает, насколько сильно первые участки отклонялись от итоговой цели и как энкодер компенсировал это на последующих сценах. Но для поиска краткого всплеска нагрузки на декодер частичный средний битрейт подходит хуже, чем скользящее окно или VBV-анализ.

Из этого следует важное практическое правило: не называйте любую кривую AVInaptic графиком битрейта без уточнения. В программе есть показатели размеров кадров, DRF и частичного среднего; они отвечают на разные вопросы. При диагностике пропусков воспроизведения нужен анализ ограничения буфера, а не только накопленный средний.

Profile compliancy и проверка буфера

AVInaptic содержит механизм проверки соответствия заранее заданному профилю. В нём используются ограничения вроде максимальной скорости чтения max_rate, размера буфера buf_size и начального заполнения buf_init. Изначальная идея — моделировать возможности конкретного аппаратного проигрывателя и отмечать участки, где поток может вызвать buffer underflow.

Эта функция требует осторожной настройки. Универсального профиля для всех устройств не существует: у разных декодеров различаются скорость чтения, объём буфера и поведение прошивки. Поэтому сообщение о нарушении профиля само по себе не равно реальной ошибке файла. Оно означает только, что выбранная модель ограничений не выдерживается.

Для современных материалов встроенный профиль MTK PAL 6000 обычно слишком узок. Официальные рекомендации прямо предлагают отключать Profile compliancy в окне Preferences, если вы не анализируете видео для оборудования, под которое профиль действительно настроен. Иначе отчёт будет заполнен предупреждениями, не имеющими практического смысла.

Что означает max_rate

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

Это объясняет, почему файл со средним битрейтом ниже ограничения всё равно может получить предупреждение. Среднее по двум часам скрывает пики. Если же профиль не соответствует устройству, предупреждение остаётся лишь математическим результатом ошибочно выбранной модели.

buf_size и buf_init

buf_size задаёт ёмкость моделируемого входного буфера. Чем он больше, тем дольше декодер может переживать локальный всплеск объёма данных. buf_init описывает начальное заполнение; при достаточном значении он в основном влияет на стартовый участок и обычно менее критичен, чем max_rate и размер буфера.

Если вы создаёте собственный профиль, значения нужно брать из документации или практических измерений целевого устройства, а не подбирать так, чтобы отчёт стал зелёным. Цель проверки — предсказать реальное ограничение, а не устранить предупреждение косметически.

Аудиодорожки: что можно узнать из отчёта

Аудиосекция AVInaptic показывает не только название кодека. В зависимости от формата там встречаются Codec ID или audio tag, число каналов, частота дискретизации, размер потока, длительность, количество кадров или chunks, тип битрейта и режим каналов. Для некоторых кодеков программа отдельно указывает параметры, прочитанные из контейнера, и данные, полученные из самого битстрима.

Разделение особенно полезно, если контейнерные поля неполны. Например, в отчёте AC-3 можно увидеть число кадров, рассчитанную длительность, фактический битрейт битстрима и режим stereo. Если контейнер не содержит корректного общего значения, полный анализ всё равно способен дать техническую картину по содержимому дорожки, когда соответствующий парсер поддерживается.

Для VBR-аудио не стоит ожидать, что одно число полностью опишет поток. Переменный битрейт по определению меняется во времени, а у lossless-кодеков размер блока зависит от сжимаемости. В таких случаях AVInaptic полезен прежде всего структурными сведениями и размером дорожки; отсутствие конкретного поля не следует заполнять ручной догадкой.

Container и bitstream

Если рядом с параметром указано (container), значение пришло из структуры контейнера. Пометка (bs) относится к bitstream — данным самой закодированной дорожки. Когда оба значения совпадают, это повышает уверенность в согласованности файла. При расхождении нужно выяснить, какое из них использует конкретный проигрыватель или рабочий инструмент.

Практический пример — частота дискретизации. Контейнер может объявлять 48 кГц, а парсер аудиокадров подтвердит то же значение. Если они расходятся, проблема может быть в некорректной сигнализации, повреждении или необычном способе упаковки. AVInaptic не переписывает такой поток автоматически, но показывает, где именно возникло противоречие.

Stream size и расчёт битрейта

Stream size — объём конкретной дорожки без остальных компонентов контейнера. Для MKV с несколькими аудиопотоками это позволяет увидеть, сколько места занимает каждый из них, а после полного анализа — получить более содержательную оценку битрейта, если заголовки сами её не предоставляют.

Не нужно путать размер дорожки с размером всего файла. Контейнер имеет собственные накладные расходы, плюс в нём могут находиться другие аудио, субтитры, вложения и служебные структуры. Поэтому сумма заметных пользователю потоков может не совпасть с размером файла байт в байт.

Delay и Max A/V diff

В AVI важны строки Delay и Max A/V diff. Delay описывает постоянное смещение дорожки относительно видеопотока. Если звук всё время опережает изображение примерно на одну и ту же величину, корректировка задержки может быть подходящим решением. Если смещение постепенно растёт, одной задержкой проблему не исправить.

Max A/V diff помогает оценить максимальное расхождение временного расположения аудио и видео в контейнере. Большое значение не всегда означает слышимый дефект: многое зависит от interleave и поведения проигрывателя. Но в сочетании с жалобой на нестабильную синхронизацию это поле стоит проверить вместе с chunks, preload и null frames.

Interleave и preload в AVI

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

При диагностике не стоит оценивать эти поля отдельно от реального симптома. Если файл нормально воспроизводится с SSD, но заикается при последовательном чтении с ограниченного устройства, interleave может иметь значение. Если же проблема повторяется в любом программном проигрывателе и сопровождается повреждёнными кадрами, причина, скорее всего, находится в другом месте.

AVInaptic показывает структуру, но не выполняет универсальную оптимизацию interleave одной кнопкой. Для перестройки порядка chunks обычно используют ремультиплексор, сохраняя исходные закодированные дорожки. Это быстрее и качественнее перекодирования, если сами битстримы исправны.

Demux: извлечение дорожек без перекодирования

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

Demux не следует путать с конвертацией. Если из MKV извлечена дорожка AAC, она останется AAC; программа не превратит её в MP3 или WAV. Аналогично видеопоток H.264 не станет MP4-файлом автоматически: MP4 — контейнер, а извлечённый элемент может быть элементарным потоком, который затем при необходимости помещают в другой контейнер подходящим muxer.

Перед извлечением удобно прочитать список дорожек и запомнить их номера. В файле с двумя аудио легко выбрать не тот язык, если ориентироваться только на порядок. Если контейнер хранит языковой тег или описание и AVInaptic его показывает, эти данные позволяют выбрать правильный поток до запуска demux.

Извлечение аудио

Чаще всего demux используют для аудиодорожки: например, чтобы проверить её отдельно, заменить контейнер или обработать звук в специализированной программе. После сохранения полезно снова определить тип получившегося файла, потому что расширение, выбранное пользователем, не меняет внутренний формат потока.

Если цель — исправить задержку, возможны два разных подхода. Для AVI AVInaptic умеет корректировать служебное смещение дорожки непосредственно в контейнере. Для других контейнеров обычно безопаснее извлечь потоки и выполнить новое мультиплексирование с заданным delay. Это разные операции и выбирать их нужно по формату исходника.

Извлечение субтитров и вложений

В Matroska субтитры могут быть отдельными дорожками, а шрифты — attachments. AVInaptic способен извлечь такие объекты, если распознал их в структуре. Это удобно перед переносом содержимого в новый MKV: можно сохранить текстовые субтитры и вспомогательные файлы без ручного поиска внутри контейнера.

После demux субтитров ASS/SSA не следует применять к ним функции редактора SRT: это другой формат. Встроенный анализ и преобразования AVInaptic для субтитров ориентированы именно на SRT. Для сложных стилей, позиционирования и шрифтов ASS нужен профильный редактор.

Изменение задержки аудио в AVI

AVInaptic умеет записывать задержку или опережение для аудиодорожек AVI без перекодирования. Функция полезна при постоянном смещении, когда звук на всём протяжении файла отстаёт или опережает на примерно одинаковое число миллисекунд. Перед изменением нужно определить знак и величину смещения, а затем сохранить резервную копию исходника.

Если звук запаздывает на 200 мс в начале и на 1200 мс ближе к концу, это не случай для статического delay. Такое поведение указывает на различие темпа, неверную длительность, пропуски кадров или проблемы таймстампов. Коррекция на 200 мс сделает старт приемлемым, но конец останется неверным.

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

FourCC и video handler

FourCC — четырёхсимвольный идентификатор видеокодека в AVI. Он помогает системе выбрать подходящий декодер, но не описывает все свойства битстрима. AVInaptic позволяет изменить FourCC и video handler без повторного кодирования, что иногда помогает старому программному или аппаратному окружению распознать совместимый поток под ожидаемым идентификатором.

Эта функция опасна при использовании вслепую. Замена XVID на другой код не преобразует XviD-битстрим в новый формат. Если выбранный декодер не умеет фактически читать данные, изменение только вводит систему в заблуждение. Поэтому FourCC меняют лишь тогда, когда известно, что два идентификатора относятся к совместимому способу декодирования в целевой среде.

При проблемах сначала сохраняют отчёт, фиксируют исходный FourCC, делают копию файла и только затем экспериментируют. Если после изменения ситуация ухудшилась, исходное значение должно быть легко восстановить. Для повреждённого или неподдерживаемого видеопотока FourCC Changer не является средством ремонта.

Специфика AVI: индексы и варианты контейнера

AVI — один из форматов, для которых AVInaptic выводит особенно много диагностических признаков. Помимо обычного AVI, в описании контейнера могут встречаться пометки OpenDML, OpenDML indexes, OpenDML multi-chunks, rec-lists, DivX Media Format и Google. Это не названия кодеков, а особенности упаковки контейнера.

Для современного программного воспроизведения многие из этих различий не критичны. Они становятся полезными, когда нужно понять поведение старой аппаратуры, потерю возможности seeking или особенности архивного AVI. Отчёт позволяет увидеть, что проблема может быть в структуре RIFF, даже если видеопоток XviD сам по себе корректен.

OpenDML

OpenDML расширяет классический AVI и позволяет обходить ограничения ранней структуры, в том числе связанные с крупными файлами. Наличие слова OpenDML не означает неисправность. Важно, какие именно расширения используются и как их понимает целевой проигрыватель.

Если AVInaptic отдельно сообщает OpenDML indexes, это означает наличие расширенных индексов. Некоторые старые устройства ориентировались только на legacy-индекс idx1 и могли плохо искать по файлу, если привычный индекс отсутствовал или был неполным. В таком случае разумнее ремультиплексировать AVI с совместимой схемой индексации, чем перекодировать видеопоток.

OpenDML multi-chunks

OpenDML multi-chunks указывает, что данные разнесены по нескольким RIFF-частям. Старые проигрыватели могли воспроизводить первый участок, но терять seeking или останавливаться при переходе к следующему. Для диагностики архивной коллекции эта пометка объясняет очень характерный симптом: файл стартует нормально, а перемотка работает только в начале.

Решение зависит от требований целевой среды. Если нужно сохранить потоки без потерь, обычно пробуют ремультиплексирование в контейнер с поддерживаемой структурой. Разбивать файл на части имеет смысл только тогда, когда устройство накладывает жёсткое ограничение на размер или структуру AVI.

rec-lists и DivX Media Format

rec-lists являются допустимым элементом AVI, но поддерживались не всеми аппаратными реализациями. Наличие такой пометки — ещё один аргумент в пользу remux, если именно старый проигрыватель не справляется с файлом. На современном программном декодере сама по себе rec-list не обязана вызывать проблему.

DivX Media Format обозначает расширения контейнера, применявшиеся экосистемой DivX. AVInaptic отмечает их отдельно от видеокодека. Это помогает не смешивать два уровня: DivX как способ кодирования видео и дополнительные структуры внутри AVI — связанные, но не идентичные понятия.

Пометка Google

В старых AVI из Google Video мог присутствовать нестандартный chunk, который AVInaptic помечает как Google. В программе предусмотрена специальная операция сохранения без этого элемента. Такая функция имеет узкую область применения: она предназначена для конкретной особенности AVI, а не для универсальной очистки любых неизвестных chunks.

Если в вашем файле нет соответствующей пометки, применять такую команду на всякий случай не нужно. Для неизвестной структуры сначала выясняют, что именно считает проблемным проигрыватель или анализатор, и только затем выбирают remux либо исправление заголовка.

Matroska: дорожки, служебные поля и полный анализ

В MKV AVInaptic показывает тип контейнера Matroska, список потоков, Codec ID, языковые отметки, muxing library и writing application, если эти элементы присутствуют. Для видео H.264 после полного анализа дополнительно появляются сведения битстрима и фактический размер видеодорожки. Это делает утилиту полезной, когда обычный краткий просмотр не даёт отдельный bitrate или stream size.

Codec ID Matroska следует читать буквально как идентификатор дорожки, например V_MPEG4/ISO/AVC для AVC или A_AC3 для AC-3. Это не имя файла и не FourCC. Сравнение таких идентификаторов помогает убедиться, что remux не изменил тип потока.

Поля Muxing library и Writing application полезны для происхождения контейнера, но не являются оценкой качества. MKV, собранный одной программой, может содержать видеопоток, созданный совсем другим энкодером. Поэтому настройки x264 ищут в блоке видеобитстрима, а не в строке writing application.

Вложения Matroska

Matroska допускает attachments — например, шрифты, необходимые ASS-субтитрам. Если AVInaptic видит вложения, их можно извлечь через demux. При переносе дорожек в новый контейнер важно не забыть такие файлы, иначе стилизованные субтитры могут выглядеть иначе на другом проигрывателе.

Сам факт наличия attachment не означает, что он обязательно используется. AVInaptic показывает структуру контейнера, но не строит полную зависимость между каждым шрифтом и стилем субтитров. Для окончательной чистки MKV нужны дополнительные инструменты.

MP4/MOV: что учитывать при анализе

AVInaptic распознаёт MP4/MOV и показывает общие сведения, список дорожек, разрешение, аспекты, частоту кадров и поддерживаемые параметры видеобитстрима. Для H.264 внутри такого контейнера возможен тот же углублённый анализ DRF, что и в других поддерживаемых контейнерах, если поток доступен парсеру.

MP4 и MOV имеют множество вариантов служебных атомов и vendor-specific метаданных, поэтому не следует ожидать от AVInaptic полного дерева контейнера, как от специализированного инспектора ISO Base Media File Format. Сильная сторона программы здесь — именно технический отчёт по медиапотокам, а не редактирование атомов.

Если к MP4 после нормального конца были приписаны посторонние байты, AVInaptic способен распознать файл и вывести заметку вида Ignored extra bytes (n). Такая запись означает, что анализатор нашёл данные после ожидаемой структуры и проигнорировал их. Это повод выяснить происхождение хвоста, но не автоматическое доказательство повреждения полезного видеопотока.

ProRes и другие MOV-потоки

Для MOV с ProRes AVInaptic может показать Codec ID, разрешение, frame/pixel/display aspect ratio и framerate. Но специализированной DRF-статистики для ProRes у программы нет: углублённый квантайзерный анализ заявлен для MPEG-4 ASP и AVC. Поэтому отчёт по ProRes будет полезен как структурная диагностика, а не как аналог H.264 DRF graph.

Это важное ограничение при работе с монтажными мастер-файлами. Если требуется анализ профиля ProRes, цветовых метаданных или покадровых QP современных кодеков, нужно подключать другой инструмент. AVInaptic не следует растягивать за пределы тех парсеров, которые у него действительно есть.

ASF/WMV, OGG/OGM и FLV

ASF/WMV, OGG, OGM и FLV входят в перечень контейнеров, которые AVInaptic умеет распознавать и анализировать. Набор сведений может быть менее подробным, чем для AVI или H.264 в MKV/MP4, потому что функции программы не одинаковы для всех форматов. Базовые поля — длительность, потоки, размеры кадра и кодеки — остаются основной целью.

Если файл открывается, но отчёт короткий, сначала нужно проверить, не является ли это естественным пределом конкретного парсера. Переход к Full analysis не гарантирует, что появится DRF: эта возможность привязана к MPEG-4 ASP и AVC, а не к самому расширению контейнера.

Для диагностических задач полезно разделять вопрос контейнер поддерживается и внутренний кодек разбирается глубоко. Например, FLV может быть распознан как контейнер, но редкий видеопоток внутри него не даст того же набора полей, что H.264.

Проверка субтитров SRT

AVInaptic можно открыть не только на видео, но и на файле SRT. В этом режиме программа разбирает последовательность записей и формирует отдельный отчёт о структуре субтитров. Функция рассчитана на совместимость и исправление формальных проблем: нумерации, временных меток, окончаний строк, лишних пробелов, пустых записей и слишком длинных строк.

Это не редактор перевода и не средство визуального тайминга по waveform. Здесь нет задачи синхронизировать каждую реплику вручную с речью. Вместо этого AVInaptic отвечает на вопрос, насколько SRT аккуратно оформлен и можно ли автоматически привести его к более предсказуемой структуре.

Analysis completed и поиск синтаксической ошибки

Поле Analysis completed показывает, удалось ли дойти до конца файла. Если парсер остановился на синтаксической ошибке, рядом полезно смотреть число уже разобранных entries. Тогда проблемную запись можно искать сразу после последней успешно обработанной, а не просматривать весь SRT вручную.

Причиной остановки может быть испорченная строка таймкода, неожиданная структура записи или другой элемент, который парсер не смог интерпретировать. После исправления SRT открывают снова и проверяют, завершилось ли чтение. Это простой способ убедиться, что формальная ошибка действительно устранена.

Line ending

AVInaptic различает окончания строк в стиле MS-DOS, Unix и Mac. Для современного программного проигрывания это редко критично, однако некоторые старые устройства и простые парсеры ожидали CRLF. При экспорте исправленного SRT программа приводит структуру к предсказуемому варианту, что помогает убрать такой класс несовместимости.

Если субтитры нормально работают в нужном окружении, менять line ending только ради красивого отчёта не обязательно. Смысл параметра — диагностировать конкретное ограничение, а не объявлять один стиль универсально правильным для всех систем.

Character encoding

В отчёте SRT указывается распознанная кодировка из тех вариантов, которые понимает соответствующий модуль. В старом руководстве описаны ISO-8859-1 и UCS-2. Это нужно учитывать при работе с кириллицей и современным UTF-8: встроенный анализатор SRT создавался под более узкий набор сценариев и не заменяет полноценный редактор кодировок.

Если русские символы отображаются неверно, не следует многократно пересохранять файл наугад. Сначала определяют реальную кодировку внешним редактором, делают копию и только затем приводят текст к формату, который понимают и AVInaptic, и целевой проигрыватель. Иначе легко получить необратимые кракозябры.

Tags used и comments

SRT часто содержит теги вроде <i> и <b>. AVInaptic перечисляет найденные теги и умеет удалить их при редактировании. Это полезно для устройств, которые показывают разметку как обычный текст или вообще ломают реплику из-за HTML-подобных конструкций.

Отдельная операция удаляет comments — в логике AVInaptic это фрагменты текста в квадратных скобках внутри записи. Перед автоматическим удалением нужно понимать содержимое: квадратные скобки могут использоваться и как значимая помета для зрителя, например обозначение звука. Если они нужны по смыслу, применять такую очистку нельзя.

Max lines per entry и Max entry length

Поля максимального числа строк и максимальной длины помогают быстро найти SRT, неудобный для ограниченного экрана. Очень длинная строка может не переноситься корректно, а запись из четырёх-пяти строк — закрывать большую часть изображения. AVInaptic умеет автоматизировать переразбиение, но решение о допустимых пределах остаётся за пользователем.

При выборе лимита лучше исходить из реального шрифта, размера экрана и правил проекта. Жёсткий предел в 30 символов, например, может создать слишком много коротких строк на современном дисплее. Утилита выполняет механическое ограничение, а не типографическую верстку с оценкой смысловых пауз.

Empty entries, superfluous lines и spaces

Empty entries — записи без полезного текста. Их наличие обычно не приносит пользы и может путать простые проигрыватели. Superfluous lines и Superfluous spaces сигнализируют о лишней структуре, которую можно нормализовать при сохранении.

Такие дефекты редко влияют на изображение или звук, но они хорошо объясняют, почему один SRT принимается устройством, а другой с визуально одинаковыми репликами — нет. AVInaptic полезен именно для формального сравнения: он показывает различия, которые не всегда заметны в обычном текстовом редакторе.

Timestamp syntax

Поле Timestamp syntax проверяет формат строк времени. Если значение отличается от OK, парсер обнаружил отклонение от ожидаемого синтаксиса. В некоторых случаях AVInaptic всё же понимает такой таймкод и при экспорте записывает его в нормализованном виде.

После автоматического сохранения новый SRT стоит открыть повторно. Если синтаксис стал OK, а количество записей и ключевые временные точки сохранились, нормализация прошла ожидаемо. Для критичных субтитров дополнительно сравнивают несколько реплик в начале, середине и конце.

Last entry и нумерация записей

Проверка Last entry помогает выявить некорректное завершение файла, а Entry numbering — пропуски, повторы или необычную последовательность номеров. Многие современные проигрыватели терпимы к таким дефектам, но аккуратная нумерация облегчает последующее редактирование и повышает совместимость простых парсеров.

При экспорте AVInaptic может сформировать последовательную структуру заново. Это безопаснее ручного массового перенумерования, но всё равно нужно убедиться, что число записей соответствует исходному смыслу и ни одна реплика не была потеряна из-за ошибки парсинга до начала редактирования.

Timestamps per entry и global timestamps

Timestamps per entry проверяет внутреннюю логичность каждой записи: время окончания должно следовать за временем начала. Global timestamps оценивает последовательность соседних entries. Так можно обнаружить странные перекрытия или перестановки временных интервалов.

Перекрытие само по себе не всегда ошибочно: некоторые субтитры намеренно держат две реплики одновременно. Поэтому предупреждение нужно сопоставлять с содержимым. AVInaptic проверяет формальную временную структуру, но не знает режиссёрского замысла и не умеет решить, оправдано ли наложение двух фраз.

Редактирование SRT в AVInaptic

После анализа SRT доступна команда редактирования, вызываемая кнопкой с буквой A или соответствующим пунктом Misc. Записи загружаются во внутреннюю базу, и операции применяются к этой рабочей копии. Исходный SRT не переписывается автоматически.

Набор функций намеренно узкий: удалить пустые entries, удалить теги, удалить comments, переразбить длинные строки, ограничить число строк, выполнить линейное преобразование временных меток, присоединить записи другого SRT и экспортировать результат. Для исправления орфографии, перевода и сложного визуального тайминга нужен другой редактор.

Удаление пустых entries

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

Если пустая запись использовалась как искусственная пауза или маркер для стороннего скрипта, AVInaptic не знает об этом назначении. Перед очисткой таких нестандартных проектов лучше сохранить оригинал и понимать, кто будет читать файл дальше.

Удаление тегов

Удаление tags превращает стилизованный SRT в обычный текст. Это повышает совместимость там, где проигрыватель не понимает <i>, <b> и сходную разметку. Однако вместе с тегами исчезает смысловое выделение: курсив для голоса за кадром или песен, жирное начертание и другие акценты.

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

Reformat entries

При переформатировании пользователь задаёт максимальную длину строки. AVInaptic разбивает слишком длинные строки, перераспределяя текст по последующим строкам. Ключевое ограничение: функция умеет увеличивать число строк за счёт разбиения, но не является полным алгоритмом верстки и не объединяет короткие строки только потому, что новый предел это допускает.

Это означает, что повторный запуск с более большим лимитом не склеит уже короткие строки обратно. Если сначала применили предел 30 символов, а затем решили использовать 50, программа не восстановит исходную компоновку. Именно поэтому оригинальный SRT стоит сохранять отдельно.

Механическое разбиение также не понимает смысловых границ на уровне диалога. Оно старается уложить строку в размер, но не заменяет ручную редактуру, где перенос ставят по синтаксису и ритму чтения.

Limit number of lines

Если запись содержит больше строк, чем разрешено, AVInaptic делит её на минимальное число новых entries. Временной интервал исходной записи распределяется между полученными частями пропорционально числу строк. Например, запись из пяти строк при лимите две превращается в три части: 2+2+1.

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

После автоматического деления полезно просмотреть места с быстрыми репликами. Если последняя часть получила слишком короткий интервал, тайминг лучше поправить вручную в специализированном subtitle editor.

Linear timestamp transform

Линейное преобразование временных меток применяется, когда расхождение можно описать формулой с постоянным смещением и масштабом времени. Это подходит для переноса SRT между версиями видео, отличающимися начальной точкой и равномерным изменением темпа, например из-за другого framerate.

Принципиально важно, чтобы ошибка была линейной. Если в середине фильма вырезана сцена, после неё появляется скачок, который одной формулой на весь файл не исправить. Тогда субтитры нужно делить на участки или редактировать в программе с несколькими синхронизационными точками.

До преобразования удобно измерить ошибку минимум в двух далеко разнесённых местах. Если в начале и конце требуются разные поправки, из них можно определить масштаб. Если же ошибка то растёт, то уменьшается, причина нелинейна и этот инструмент не подходит.

Append другого SRT

Команда append предназначена для случая, когда фильм и субтитры разбиты на две части, а затем видео объединяется. Сначала открывают SRT первой части, переходят в режим редактирования, выбирают добавление второго файла и указывают длительность первой видеочасти. AVInaptic сдвигает таймкоды второго SRT на эту длительность и присоединяет entries.

Длительность можно ввести вручную или получить из первой части видео. Второй вариант снижает риск ошибки при переписывании часов, минут, секунд и миллисекунд. После присоединения результат экспортируют в новый SRT и повторно анализируют.

Если между частями видео был вырезан фрагмент, просто использовать полную длительность первой части недостаточно: сдвиг должен соответствовать фактической точке склейки. AVInaptic не может угадать монтажное изменение, поэтому перед append нужно знать реальную временную геометрию объединённого файла.

Preferences и файл avinaptic.cfg

Настройки AVInaptic хранятся в avinaptic.cfg. Среди практически важных параметров — включение проверки Profile compliancy и автоматических comments в отчёте. Конфигурацию можно переносить между выпусками программы, но вместе с ней переносятся и старые значения, поэтому после копирования файла настроек стоит проверить именно эти пункты.

Для обычного анализа современных видео профиль MTK PAL 6000 лучше отключить: его ограничения создавались для значительно более узкого класса аппаратуры. То же относится к комментариям, которые автоматически оценивают некоторые параметры с точки зрения старых проигрывателей. Они могут отвлекать от фактических технических данных.

Если же AVInaptic используется для конкретного legacy-устройства, профиль имеет смысл настроить под реальные ограничения. Тогда предупреждения снова приобретают практическую ценность: они отвечают не на вопрос современный ли файл, а на вопрос соответствует ли он заданной модели декодера.

Язык интерфейса

В распространённых сборках AVInaptic доступны английский и итальянский интерфейсы. Русской локализации нет. Для работы с документацией удобнее выбирать английский: названия полей Frame aspect ratio, Pixel aspect ratio, Display aspect ratio, Null frames, Full analysis и DRF graph легче сопоставлять с терминологией кодеков.

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

Практический сценарий: почему файл не воспроизводится

Начинать диагностику следует с базового отчёта. Сначала проверяют контейнер и Codec ID видеодорожки: действительно ли устройство или программа поддерживает такую комбинацию. Затем смотрят разрешение, частоту кадров, DAR/PAR и аудиокодек. Уже на этом этапе часто обнаруживается очевидное несоответствие техническим требованиям.

Если это MPEG-4 ASP, дополнительно проверяют QPel, GMC, interlaced, матрицу квантования и packed bitstream. Если H.264 — профиль, level, reference frames и другие параметры. При AVI также смотрят варианты OpenDML, индексы, multi-chunks и null frames. Эти строки объясняют случаи, когда такой же кодек на другом файле работает.

После нахождения отличия выбирают минимально разрушительное исправление. Проблему FourCC иногда решает изменение идентификатора; packed bitstream — перепаковка; несовместимый контейнер — remux. QPel, GMC или неподдерживаемые инструменты кодека обычно требуют перекодирования. AVInaptic помогает выбрать направление, но не подменяет инструмент исправления.

Практический сценарий: сравнение двух энкодов H.264

Для сопоставления двух H.264-файлов сначала убеждаются, что они созданы из одного источника и имеют одинаковую длительность. Затем сравнивают разрешение, framerate, stream size и bitrate. После Full analysis переходят к структуре I/P/B, среднему DRF, стандартному отклонению и распределению DRF.

Далее полезно изучить user data x264. Различия в ref, bframes, me, subme, trellis, psy_rd, aq, crf и VBV могут объяснить, почему файлы отличаются по размеру и характеру артефактов. Если строки энкодера отсутствуют, не нужно придумывать параметры по косвенным признакам.

График DRF используют для локализации участков, где квантование расходится сильнее всего. Затем эти моменты просматривают в исходном видео. Такой порядок надёжнее, чем выбирать лучший файл по среднему битрейту или одной цифре DRF.

Практический сценарий: подготовка к remux

Перед переносом потоков в другой контейнер AVInaptic используют как инвентаризацию. Сохраняют отчёт, фиксируют число дорожек, Codec ID, языки, размер потоков, framerate, aspect ratio, задержки и вложения. Затем выполняют demux или используют отдельный muxer, а после сборки анализируют новый файл тем же способом.

Цель сравнения — убедиться, что видео и аудио не были случайно перекодированы и сохранили основные параметры. Размер контейнера может измениться из-за накладных расходов, но stream size и свойства самих потоков должны быть логически согласованы. Изменение Codec ID контейнера допустимо, если того требует новый формат упаковки.

Особое внимание уделяют delay. При remux контейнерные временные метки могут интерпретироваться иначе, поэтому после операции важно не только сравнить отчёты, но и проверить синхронизацию в нескольких точках.

Практический сценарий: диагностика рассинхронизации

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

При постоянном сдвиге смотрят Delay аудиодорожки и контейнерные временные параметры. В AVI можно аккуратно изменить задержку. При накопительном — сравнивают длительность видео и аудио, framerate, количество кадров и наличие null frames. При скачке ищут повреждение, пропуск данных или монтажную границу.

Очень полезно не смешивать причины. Изменение delay не исправляет неверный темп; изменение framerate не исправляет отсутствующий кусок аудио; remux не восстанавливает повреждённые кадры. Отчёт AVInaptic нужен именно для классификации проблемы до вмешательства.

Практический сценарий: проверка файла перед субтитрованием

Перед созданием SRT полезно точно определить framerate и длительность видео. AVInaptic показывает эти параметры без необходимости доверять имени файла или настройкам проекта. Если исходник имеет 23.976 fps, а subtitle editor создан под 25 fps, ошибка может проявиться не сразу, а нарастать к концу.

После подготовки субтитров SRT можно открыть в AVInaptic и проверить timestamp syntax, нумерацию, пустые entries, максимальную длину и число строк. Такой контроль не заменяет языковую вычитку, но ловит формальные дефекты, которые легко пропустить визуально.

Если SRT предназначен для ограниченного проигрывателя, можно удалить неподдерживаемые теги и переразбить строки. Результат сохраняют как новый файл, чтобы всегда иметь исходную версию с полной разметкой.

Практический сценарий: технический паспорт архива

AVInaptic удобен для текстового паспорта файла. Сохранив отчёт рядом с медиаданными, можно спустя время узнать, какой контейнер и кодеки использовались, каково разрешение, сколько дорожек было внутри, какой размер занимал видеопоток и какие параметры x264 удалось извлечь.

Для архива особенно полезно сохранять полный отчёт на MPEG-4 ASP/H.264, а не только быстрый. Тогда остаются статистика кадров и DRF. Однако текстовый отчёт не является криптографическим подтверждением идентичности файла: если важна проверка неизменности, отдельно нужен хеш, который AVInaptic не заменяет.

Также не стоит считать отчёт резервной копией контейнера. По нему нельзя восстановить видео, аудио или вложения. Это техническое описание, а не средство восстановления данных.

Что делать, если AVInaptic показывает слишком короткий отчёт

Короткий отчёт чаще всего означает одну из трёх вещей: выбран быстрый режим, контейнер распознан, но конкретный поток поддерживается ограниченно, либо файл вообще не соответствует ожидаемому формату. Сначала сравните строки File type, Container и список track. Если контейнер определён корректно, а видео MPEG-4 ASP или AVC, имеет смысл запустить Full analysis.

Если Full analysis не добавляет ожидаемые поля, не нужно запускать его повторно в надежде получить другой результат. Проверьте Codec ID: DRF-модуль рассчитан именно на MPEG-4 ASP и H.264. Для HEVC, AV1, VP9, ProRes и других кодеков понадобится другой инструмент, если нужен покадровый анализ квантования.

Если же File type выглядит как произвольные данные, хотя расширение знакомое, попробуйте открыть файл другим анализатором. Совпадение результата нескольких программ поможет понять, повреждён ли контейнер или AVInaptic просто не умеет разбирать конкретный вариант.

Что делать, если контейнер распознан неправильно

Сначала исключите простое переименование. Расширение можно изменить за секунду, но сигнатура и структура данных от этого не меняются. Если AVInaptic и второй независимый анализатор указывают один и тот же контейнер, доверять содержимому разумнее, чем имени.

У частично повреждённого файла заголовок может отсутствовать или быть обрезан, поэтому AVInaptic не получает необходимых опорных структур. В таком случае hex dump или сообщение о неизвестных данных полезнее, чем попытка насильно назначить FourCC. FourCC относится к видеопотоку AVI и не превращает произвольный файл в AVI.

Для MP4 с посторонними байтами после корректной структуры возможна заметка Ignored extra bytes. Она отличается от полного отказа распознавания: программа смогла разобрать контейнер, но обнаружила лишний хвост. Сначала сохраните оригинал и выясните источник этих данных, прежде чем обрезать файл.

Что делать, если Full analysis занимает долгое время

Полный анализ по определению читает значительно больше данных, чем быстрый. На длинном H.264-файле это нормальная причина задержки. Если вам нужны только Codec ID, разрешение, framerate и список аудио, запускать полный проход нет смысла — быстрый отчёт даст эти сведения с меньшими затратами.

Когда задача требует DRF, дождитесь завершения одного прохода и затем сохраните результат. Не стоит одновременно сканировать несколько огромных файлов отдельными экземплярами AVInaptic на системе с ограниченными ресурсами: это не ускоряет последовательное чтение диска и усложняет диагностику, если один из файлов повреждён.

Если конкретный файл стабильно останавливает анализ, а другие файлы того же кодека обрабатываются, сохраните быстрый отчёт и сравните его со вторым анализатором. Такое различие полезнее многократных попыток: оно помогает отделить проблему файла от общего ограничения программы.

Почему в отчёте появились десятки предупреждений Profile compliancy

Наиболее вероятная причина — включён профиль, предназначенный для старого аппаратного ограничения, например MTK PAL 6000. Современное HD-видео закономерно нарушает его по разрешению, framerate или скоростным параметрам. Эти предупреждения не означают, что видео испорчено.

Откройте Preferences и отключите Profile compliancy, если у вас нет конкретного устройства, для которого проверяются ограничения. Если устройство есть, создайте или выберите профиль, отражающий его реальные требования. Только тогда сообщения о buffer underflow и несоответствии параметров становятся практически значимыми.

Почему данные AVInaptic отличаются от MediaInfo

Программы используют разные парсеры и не всегда получают значение из одного источника. MediaInfo обычно очень широко читает контейнерные и потоковые метаданные, а AVInaptic для поддерживаемых ASP/AVC может выполнить полный битстрим-анализ. Поэтому bitrate, stream size или длительность иногда рассчитываются разными методами.

Расхождение не следует решать голосованием какая программа лучше. Нужно понять происхождение конкретного поля. Если одно значение помечено как container, а другое получено из bitstream, разница уже объяснима. Для спорного параметра полезно подключить ffprobe и посмотреть пакеты/кадры или контейнерные timestamps.

Если речь об aspect ratio, сравните FAR, PAR и DAR отдельно. Один анализатор может показывать только итоговый DAR, другой — сигнализацию из нескольких уровней. Сводить разные определения в одну колонку неправильно.

Почему DRF нельзя использовать как рейтинг качества

DRF описывает квантование, а качество зависит также от исходника, разрешения, энкодера, психовизуальных алгоритмов, motion estimation, фильтрации, структуры GOP и требований к битрейту. Два файла с одинаковым Average DRF могут заметно различаться визуально.

Особенно бессмысленно сравнивать численное значение между MPEG-4 ASP и H.264. Шкалы и механизмы квантования у них различаются. Даже внутри H.264 CRF 18 в одном энкодере не означает автоматическое соответствие конкретному DRF во всех кадрах.

Используйте DRF как диагностическую статистику. Он помогает найти необычные зоны и сопоставить два близких энкода. Финальный вывод о качестве делается по визуальному сравнению с одинаковым исходником и, при необходимости, по подходящим объективным метрикам.

Ограничения AVInaptic, которые важно учитывать

• Нет пакетного режима для серии файлов. Основной графический процесс рассчитан на открытие и анализ одного файла за раз, поэтому для большой медиатеки удобнее инструмент с batch-выводом или скриптуемый CLI.
• DRF-анализ ограничен MPEG-4 ASP и AVC. У HEVC, AV1, VP9, ProRes и других кодеков AVInaptic не предоставляет аналогичный встроенный график квантования.
• Поддержка контейнеров неодинакова по глубине. То, что формат открывается, ещё не означает, что для него будут доступны все поля и операции, характерные для AVI или H.264.
• Это не перекодировщик и не универсальный ремонтник. Программа умеет менять отдельные поля AVI и работать с SRT, но не выполняет преобразование кодеков, сложный remux и восстановление повреждённых медиаданных.
• Интерфейс не локализован на русский. Практическая терминология представлена главным образом на английском или итальянском, поэтому полезно знать названия параметров контейнеров и кодеков.
• Часть проверок ориентирована на старую аппаратуру. Profile compliancy и автоматические comments могут создавать нерелевантные предупреждения, если их не отключить или не настроить под реальную цель.
• SRT-модуль узкоспециализирован. Он исправляет структуру и таймстампы, но не заменяет современный редактор субтитров с waveform, spellcheck и визуальным позиционированием.

Что AVInaptic не делает

Программа не воспроизводит видео как полноценный медиаплеер, не выполняет монтаж, цветокоррекцию, шумоподавление, масштабирование и перекодирование. Наличие сведений о x264 не означает, что из AVInaptic можно запустить x264 с теми же настройками. График DRF — анализ уже готового битстрима.

Demux не равен remux: извлечь дорожку можно, но собрать новый контейнер с произвольной схемой дорожек удобнее отдельным мультиплексором. Изменение FourCC не меняет кодек, а редактирование delay не меняет скорость звука.

Эти границы делают AVInaptic полезным именно как диагностический инструмент. Чем точнее сформулирован вопрос — какой FourCC?, есть ли QPel?, каков PAR?, где растёт DRF?, какие дорожки в MKV? — тем меньше риск ожидать от программы функцию, которой у неё нет.

Сравнение AVInaptic с аналогами

Программа	Лучше подходит для	Главное ограничение
AVInaptic	Глубокого анализа MPEG-4 ASP/H.264, DRF-графиков, диагностики AVI, demux и формальных исправлений SRT	DRF только для ASP/AVC, нет удобного пакетного анализа
MediaInfo	Быстрого универсального чтения технических и теговых данных большого числа современных аудио- и видеоформатов	Не даёт встроенный AVInaptic-подобный DRF-график и не правит AVI/SRT таким способом
ffprobe	Скриптов, автоматизации, JSON/XML/CSV-подобного вывода, анализа streams, packets и frames в экосистеме FFmpeg	Командная строка и большой объём низкоуровневых данных требуют подготовки
GSpot	Поиска нужного декодера, проверки установленных Windows-кодеков и диагностики legacy AVI/MPEG/DirectShow	Слабее подходит для современных контейнеров и не имеет AVInaptic DRF/SRT-инструментов
VideoInspector	Проверки кодеков воспроизведения, базовых параметров видео, batch-отчётов и сведений об установленных компонентах	Не предоставляет столь подробный DRF-анализ MPEG-4 ASP/H.264 и SRT-редактирование

Если нужно быстро получить стандартную карточку практически любого современного медиафайла, рациональнее начинать с MediaInfo. Если требуется автоматическая обработка сотен файлов, извлечение конкретных полей или просмотр пакетов и кадров, ffprobe заметно удобнее. GSpot остаётся характерным выбором для диагностики старого Windows-кодекного окружения, а VideoInspector — для более простого графического поиска причин воспроизведения.

AVInaptic стоит выбирать, когда важны его специфические сильные стороны: подробный разбор AVI, параметры MPEG-4 ASP, user data H.264/x264, Full analysis, распределение и график DRF, расчёт размеров потоков, извлечение дорожек и проверка SRT. На практике эти утилиты не взаимоисключающие: сохранённый отчёт AVInaptic и независимый вывод MediaInfo или ffprobe дают более надёжную диагностику спорного файла, чем попытка заставить один анализатор отвечать на все вопросы.

Как выбрать правильный режим анализа для конкретной задачи

Задача	Что открыть в AVInaptic	На что смотреть
Узнать кодек и контейнер	Обычное открытие файла	File type, Container, Codec ID, FourCC
Проверить геометрию	Обычный отчёт	Resolution, FAR, PAR, DAR
Найти причину отказа старого AVI	Обычный отчёт, при ASP — полный	OpenDML, QPel, GMC, interlaced, matrix, packed bitstream, null frames
Сравнить H.264 энкоды	Full analysis/DRF Graph	Stream size, x264 user data, I/P/B, Average DRF, distribution
Извлечь дорожку	Обычный отчёт + Demux	Номер, Codec ID, язык, тип потока
Исправить постоянный A/V delay в AVI	Обычный отчёт	Delay, Max A/V diff, длительности, затем правка копии
Проверить SRT	Открыть SRT	Analysis completed, timestamps, numbering, lines, tags
Проверить старое устройство	Отчёт + настроенный профиль	Profile compliancy, buffer underflows и ограничения устройства

Рабочие правила, которые уменьшают число ложных выводов

1. Сначала определяйте контейнер и кодек, а уже затем выбирайте глубину анализа.
2. Не сравнивайте DRF разных семейств кодеков как одну шкалу качества.
3. Различайте контейнерные значения и параметры bitstream.
4. Для спорного аспекта всегда смотрите FAR, PAR и DAR вместе.
5. Постоянный delay не используйте для исправления нарастающей рассинхронизации.
6. FourCC меняйте только на резервной копии и только при понятной совместимости декодера.
7. Profile compliancy держите выключенным, если у вас нет соответствующего целевого профиля.
8. Перед demux зафиксируйте номера дорожек, языки и Codec ID.
9. SRT экспортируйте в новый файл и после преобразований анализируйте повторно.
10. Если результат важен, подтверждайте спорные поля вторым анализатором.

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

Показывает ли программа параметры x264?

Если x264 записал служебные user data в H.264-битстрим и AVInaptic их распознал, в отчёте появляется набор параметров кодирования. Это могут быть CABAC, ref, deblock, motion estimation, subme, trellis, B-frames, keyint, CRF/VBV и другие значения. Полнота списка зависит от данных внутри конкретного потока.

Можно ли по отчёту восстановить точную команду x264?

Не гарантированно. User data полезны для реконструкции существенных настроек, но не являются полным проектом энкодера. Часть значений могла быть умолчанием, часть — не сохраниться, а графическая оболочка могла преобразовать параметры до запуска x264.

Работает ли DRF graph с HEVC?

Нет, встроенный DRF-анализ AVInaptic предназначен для MPEG-4 ASP и AVC/H.264. HEVC может быть распознан в некоторых контейнерных сценариях лишь на уровне доступных общих данных, но рассчитывать на тот же DRF-модуль нельзя.

Почему у H.264 DRF выше, чем у XviD?

Числовые шкалы квантования отличаются. Для AVC диапазон значительно шире, поэтому прямое сравнение числа с MPEG-4 ASP некорректно. Сравнивайте статистику только внутри одного семейства кодека и в близких условиях.

Можно ли анализировать MKV?

Да. AVInaptic показывает Matroska-контейнер, дорожки, Codec ID, языки и служебные поля, а для подходящего H.264 выполняет полный анализ битстрима. Вложения Matroska также могут быть доступны для извлечения.

Можно ли анализировать MP4 и MOV?

Да. Программа распознаёт MP4/MOV и читает основные параметры потоков. Для AVC возможен углублённый анализ. Однако AVInaptic не является редактором атомов ISO Base Media File Format и не показывает исчерпывающее дерево всех служебных боксов.

Можно ли извлечь звук из видео?

Да, через Demux можно извлекать доступные дорожки. Это не конвертация: аудиопоток сохраняется в исходном кодеке. Если нужен WAV, MP3 или другой новый формат, понадобится отдельное декодирование/перекодирование.

Можно ли извлечь субтитры из MKV?

Если AVInaptic распознал соответствующую дорожку, demux позволяет сохранить её отдельно. Дальнейшее редактирование зависит от формата: встроенные операции нормализации предназначены для SRT, а не для полного набора возможностей ASS/SSA.

Можно ли менять задержку звука без перекодирования?

Для AVI AVInaptic умеет менять контейнерный delay аудиодорожек. Это подходит при постоянном смещении. Нарастающая или скачкообразная рассинхронизация требует другой диагностики и, возможно, remux либо переработки временной шкалы.

Что даст изменение FourCC?

Оно изменит идентификатор видеопотока в AVI, чтобы система или устройство выбрали ожидаемый декодер. Сам видеобитстрим не преобразуется. Неправильный FourCC способен ухудшить ситуацию, поэтому изменение делают только с пониманием совместимости.

Что означает Null frames: 0?

Это означает, что AVInaptic не обнаружил контейнерных null frames в анализируемом AVI. Для рабочих цепочек, чувствительных к временным дыркам, нулевое значение является удобным подтверждением отсутствия именно этого механизма.

Что означает Ignored extra bytes?

Программа распознала основную структуру MP4, но обнаружила дополнительные байты после ожидаемого конца и не стала включать их в нормальный разбор. Нужно выяснить, откуда появился хвост; само сообщение не означает автоматическое повреждение полезного потока.

Почему Profile compliancy ругается на обычное HD-видео?

Вероятно, включён профиль для старого аппаратного декодера с низкими пределами. Отключите эту проверку в Preferences, если не анализируете файл под конкретное устройство. Для реального целевого устройства используйте профиль с его собственными ограничениями.

Есть ли пакетный анализ папки?

В основной графической работе AVInaptic ориентирован на один файл за раз. Для массовой инвентаризации медиатеки удобнее MediaInfo CLI или ffprobe со скриптом, а AVInaptic оставлять для файлов, которые требуют его глубокого ASP/AVC-анализа.

Можно ли редактировать SRT непосредственно?

Операции применяются к рабочей копии записей, а исходный SRT не переписывается. Чтобы получить изменённый файл, нужно экспортировать записи в новый SRT. Закрытие окна без экспорта отменяет результат этой рабочей сессии.

Умеет ли AVInaptic исправлять таймкоды SRT?

Он умеет нормализовать синтаксис при пересохранении и выполнять линейное преобразование timestamps. Это хорошо для постоянного смещения и равномерного изменения темпа, но не решает сложную нелинейную синхронизацию с несколькими монтажными разрывами.

Подходит ли AVInaptic для проверки субъективного качества видео?

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

Итоговый подход к AVInaptic

AVInaptic наиболее полезен там, где простого списка кодек, разрешение, битрейт недостаточно. Он раскрывает структуру AVI, показывает FAR/PAR/DAR, задержки и null frames, извлекает технические параметры MPEG-4 ASP и H.264, умеет сделать полный DRF-анализ и позволяет сохранить подробный текстовый отчёт. Это даёт материал для точной диагностики, а не только для общего описания файла.

Вторая сильная область — небольшие операции вокруг контейнера и субтитров: demux дорожек, изменение delay и FourCC в AVI, проверка SRT, очистка формальной структуры и линейная коррекция временных меток. Эти функции нужно воспринимать как специализированные инструменты, а не как полноценный видеоредактор.

Работать с программой эффективнее по принципу сначала измерить, затем менять. Быстрый отчёт отвечает на базовые вопросы, Full analysis включается только для подходящего битстрима и конкретной необходимости, а любое изменение контейнера делается на копии. При спорных параметрах результат подтверждается MediaInfo или ffprobe. Такой порядок позволяет использовать сильные стороны AVInaptic без попыток превратить его в средство для задач, которые он не решает.