DGAVCDec

DGAVCDec позволяет проиндексировать поток AVC/H.264 в DGAVCIndex, сохранить проект DGA и открыть его через AVCSource в AviSynth для покадрового доступа, фильтрации и последующего кодирования без предварительного преобразования видео в промежуточный файл.

Основная логика работы состоит из двух этапов: DGAVCIndex анализирует исходный H.264-поток и создаёт небольшой индексный файл с расширением DGA, а DGAVCDecode.dll использует этот индекс как источник кадров в AviSynth. Такой подход особенно удобен, когда нужен воспроизводимый доступ к конкретным кадрам транспортного потока, а не чтение через системную цепочку DirectShow, которая зависит от установленных сплиттеров и декодеров.

DGAVCDec рассчитан прежде всего на элементарные AVC/H.264-потоки и транспортные контейнеры TS/M2TS. MP4 и MKV не следует воспринимать как прямые входные контейнеры для этой программы: если видео находится внутри такого файла, типичный рабочий путь заключается в извлечении H.264-дорожки или в выборе другого индексатора, умеющего читать контейнер напрямую. Именно эта узкая специализация определяет сильные стороны программы и одновременно объясняет большинство её ограничений.

Скачать DGAVCDec

Оценка 9.7Рекомендуем
  • Конвертация видео
  • Сжатие файлов
  • Просто для новичков
Скачать бесплатно на Windows
Лучшая альтернатива
DGAVCDec
Оценка 8.5
  • Нет прямого MP4/MKV
  • Нужен AviSynth 32-bit
  • Ограничен POC type 0
Скачать DGAVCDec
Загрузка начнётся после нажатия

Что именно делает DGAVCDec

Окно DGAVCIndex с открытым видеопотоком H.264

DGAVCDec не является видеоредактором и не выполняет полноценное перекодирование сам по себе. Его задача — подготовить AVC/H.264-видео так, чтобы к нему можно было обращаться из AviSynth по кадрам. В практической цепочке DGAVCIndex открывает поток, анализирует структуру NAL-единиц, порядок декодирования и опорные точки, после чего сохраняет проект DGA. Затем AviSynth-функция AVCSource(), предоставляемая библиотекой DGAVCDecode.dll, читает этот проект и выдаёт декодированные кадры скрипту.

Ключевая выгода индексации заключается в отделении анализа длинного сжатого потока от последующих операций. Кодек H.264 активно использует межкадровые зависимости: чтобы получить произвольный B- или P-кадр, декодеру нередко нужно начать с более ранней опорной картинки. DGA хранит служебную информацию, позволяющую не искать нужную структуру заново при каждом запуске скрипта. Поэтому индекс особенно полезен в цепочках, где один и тот же исходник многократно открывается для кропа, деинтерлейса, ресайза, проверки отдельных сцен и кодирования.

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

Второй принципиальный момент — разделение видео и звука. AVCSource() возвращает видеоклип. Звуковую дорожку при необходимости демультиплексируют отдельно и подключают в AviSynth подходящим аудио-источником либо кодируют независимо и сводят уже на этапе мультиплексирования. DGAVCIndex умеет извлекать некоторые звуковые потоки из TS/M2TS, но его нельзя считать универсальным современным аудиодемультиплексором.

Состав рабочей связки: DGAVCIndex, DGA и DGAVCDecode.dll

Стартовый экран DGAVCIndex из комплекта программы

Пользователь взаимодействует в первую очередь с DGAVCIndex.exe. Это окно просмотра и индексации: в нём открывают AVC/H.264, проверяют, что поток распознан, переходят по кадрам, при необходимости выбирают режим обработки флагов полей и настраивают извлечение аудио. Команда сохранения проекта запускает проход по материалу и создаёт файл .dga.

Файл DGA является промежуточным проектом, а не готовым медиаконтейнером. Его назначение — связать исходный битовый поток с декодером DGAVCDecode. С практической точки зрения DGA следует хранить рядом с исходником или, как минимум, не менять структуру каталогов до окончания работы. Если проект создавался в автоматизированной временной папке, а затем исходный H.264 был удалён очисткой временных файлов, один оставшийся DGA бесполезен.

DGAVCDecode.dll подключается к AviSynth как внешний source-фильтр. Минимальный скрипт выглядит так: LoadPlugin("C:\Tools\DGAVCDec\DGAVCDecode.dll"), а следующая строка — AVCSource("D:\Video\source.dga"). Если DLL лежит в каталоге автозагрузки плагинов совместимой сборки AviSynth, явный LoadPlugin() может быть не нужен, однако для переносимой и понятной конфигурации абсолютный путь часто удобнее.

Третья часть цепочки — сам AviSynth и приложение, которое открывает AVS-скрипт. Это может быть кодировщик, фронтенд, VirtualDub совместимой разрядности или другая программа, понимающая AviSynth. DGAVCDec здесь отвечает только за источник кадров; обрезка, изменение размера, восстановление прогрессивной развёртки, шумоподавление и собственно сжатие выполняются другими фильтрами и кодировщиками.

Какие исходники подходят для DGAVCIndex

Наиболее прямой вариант — элементарный H.264/AVC-поток, извлечённый из контейнера. На диске такие файлы встречаются с расширениями .264, .h264 или .avc; расширение само по себе не является главным признаком, поскольку DGAVCIndex ориентируется на содержимое. Второй тип источника — транспортные потоки, прежде всего TS и M2TS, где AVC-видео располагается среди других PID вместе с аудио и служебными таблицами.

Для M2TS с Blu-ray или камер AVCHD важно сначала определить, действительно ли видеодорожка закодирована в AVC. Один и тот же контейнер может содержать разные видеокодеки, и наличие расширения M2TS не гарантирует H.264. Если внутри MPEG-2 Video, логичнее использовать DGIndex/DGDecode из семейства DGMPGDec; если VC-1 — DGAVCDec к нему не подходит.

MP4 и Matroska представляют отдельный случай. В справочных материалах по AviSynth для DGAVCDec прямо рекомендуют сначала получить сырой AVC/H.264-поток, а уже затем индексировать его. Это не то же самое, что обычное переименование расширения: контейнер содержит таблицы, временные метки и другие данные, которые необходимо корректно разобрать демультиплексором. Для MKV таким инструментом традиционно служит извлечение нужной дорожки, для MP4 — аналогичная операция подходящим демультиплексором.

Если требуется просто открыть современный MP4 или MKV без дополнительного извлечения дорожки, DGAVCDec обычно проигрывает FFMS2 или L-SMASH Works по удобству. Сильная сторона DGAVCDec проявляется там, где источник уже является AVC elementary stream либо TS/M2TS и нужен именно DGA/AVCSource-процесс.

ИсточникПрактический путьЧто учитывать
*.264 / *.h264 / *.avcОткрыть напрямую в DGAVCIndexЭто наиболее естественный вход для индексатора
*.tsОткрыть напрямую при AVC-видеодорожкеПроверить PID видео и аудио
*.m2ts / *.mtsОткрыть напрямую, если поток распознаётсяУ камер встречаются сложные interlaced/PAFF варианты
*.mkvИзвлечь H.264 либо использовать другой source-фильтрПрямое чтение контейнера не является штатным сценарием
*.mp4Извлечь H.264 либо использовать FFMS2/L-SMASH WorksПереименование файла не заменяет демультиплексирование

Открытие видео в DGAVCIndex

Базовая операция выполняется через File → Open. После выбора поддерживаемого источника DGAVCIndex анализирует начало потока и показывает изображение в окне просмотра. В учебных примерах с M2TS этот шаг используется прежде всего для визуальной проверки того, что выбран нужный видеопоток и программа действительно декодирует кадры, а уже затем выполняется сохранение проекта.

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

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

Если DGAVCIndex сразу выдаёт ошибку на конкретном TS/M2TS, полезно отделить проблему контейнера от проблемы декодирования. Практический способ — демультиплексировать только AVC-видеодорожку и попробовать индексировать полученный elementary stream. Если сырой поток открывается, причиной мог быть разбор конкретной транспортной структуры; если не открывается и он, вероятнее несовместимость относится к самому H.264-потоку.

Интерфейс и навигация по кадрам

Главное окно DGAVCIndex построено вокруг области просмотра, строки меню и элементов навигации. По духу оно близко к DGIndex: задача интерфейса не в монтаже, а в анализе потока и выборе позиции. Можно перемещаться по материалу, просматривать декодированные кадры и оценивать, как программа реагирует на границы GOP и точки, с которых возможен надёжный вход в декодирование.

Для H.264 случайный доступ принципиально зависит от структуры самого потока. В ограничениях DGAVCDec отдельно отмечалось, что быстрый переход работает лучше, если в материале достаточно IDR-кадров либо recovery point SEI. Индекс не создаёт новые точки независимого декодирования; он лишь описывает существующие. Поэтому два одинаковых по длительности H.264-файла могут заметно различаться по удобству перемотки.

При проверке проблемного источника полезно сравнивать последовательный просмотр и резкие переходы по таймлайну. Если артефакт появляется только после прыжка далеко вперёд, а при последовательном декодировании от ранней точки кадры правильные, это может указывать на проблему восстановления состояния декодера в конкретной GOP-структуре. Для старого AVC-декодера подобная диагностика важнее, чем для современных source-фильтров с более зрелой реализацией seeking.

Опция Display HD Full Sized, упоминаемая в изменениях DGAVCDec 1.0.9, относится к отображению HD-кадра в просмотрщике. Она полезна, когда требуется оценить пиксельную структуру без уменьшенного предпросмотра. При этом отображение в окне не следует смешивать с тем, что выдаёт AviSynth: размер и формат кадра в AVCSource() определяются декодированным источником, а не масштабом окна DGAVCIndex.

Меню Video и режимы Field Operation

На реальных снимках интерфейса в меню Video виден пункт Field Operation с вариантами Honor Pulldown Flags, Ignore Pulldown Flags и Forced Film. Эти режимы знакомы пользователям DGIndex, но при H.264 их нужно применять осмысленно: они связаны с интерпретацией повторов полей и признаков, влияющих на выдаваемую последовательность, а не являются универсальным деинтерлейсером.

Honor Pulldown Flags означает следование флагам, присутствующим в потоке. Такой выбор логичен, когда структура содержит корректно расставленные признаки повторения полей и требуется воспроизвести авторскую временную последовательность. Ignore Pulldown Flags нужен для случаев, когда пользователь намеренно хочет анализировать кодированные кадры без применения этих повторов. Разница особенно заметна на материале с телесин-паттернами.

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

Сам DGAVCIndex не заменяет TFM/TDecimate, QTGMC, Yadif или другие фильтры восстановления прогрессивной последовательности. Его field operation определяет, как источник отдаёт кадры и поля, а сложная обработка выполняется уже в AviSynth. Для проблемного материала полезно сначала получить максимально предсказуемый источник, а затем отдельно решать задачу IVTC или деинтерлейса.

YUV → RGB и сохранение кадров

В меню Video также присутствует подменю YUV → RGB. Оно относится к преобразованию для отображения и получения RGB-представления, которое требуется экрану или сохранению изображения. Для рабочего видеопайплайна важно не переносить настройки окна просмотра на AviSynth автоматически: AVCSource() предназначен для передачи декодированного видеоклипа в скрипт, где дальнейшее преобразование цветового пространства контролируется отдельными функциями.

DGAVCIndex использовался и для сохранения отдельных кадров. Пользовательские отзывы о программе прямо упоминают захват индивидуальных кадров из H.264 TS. Это удобно для диагностики, сравнения сцен и поиска повреждённых мест. Однако снимок экрана, полученный через RGB-конверсию, не равнозначен исходным YUV-данным: на него влияет матрица преобразования, уровни и реализация RGB-конвертера.

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

Если цель — не картинка для статьи, а контроль пикселей перед кодированием, безопаснее открыть DGA через AviSynth и анализировать кадр в редакторе/просмотрщике, который не вносит неизвестную цветовую конверсию. Там же можно явно задать ConvertToRGB с нужной матрицей, если RGB действительно необходим.

Аудио: Audio Demux и выбор дорожки

В практических руководствах по DGAVCIndex для M2TS используется меню Audio → Audio Demux. Диалог показывает найденные аудиопотоки и позволяет выбрать дорожку для извлечения. После настройки сохранение проекта создаёт DGA и, если аудио поддерживается и выбрано, отдельный звуковой файл. Для AC-3 такой сценарий был типичным: рядом с проектом появлялась дорожка AC3, которую затем открывали отдельным AviSynth-аудиофильтром или передавали кодировщику.

Демультиплексирование здесь не означает декодирование звука в PCM. Если DGAVCIndex извлекает AC-3, результат остаётся AC-3 elementary stream. Это выгодно, когда звук нужно сохранить без перекодирования: достаточно учесть задержку и позже смультиплексировать его с новым видео. Если же нужен WAV или другая обработка, декодирование выполняется отдельным инструментом.

На транспортном потоке с несколькими дорожками нельзя выбирать аудио только по порядковому номеру, не проверив содержимое. PID, язык, количество каналов и формат могут отличаться. Особенно это важно для записей телевидения и Blu-ray, где рядом могут находиться AC-3, DTS, дополнительные комментарии и альтернативные языки. DGAVCIndex решает задачу выбора потока, но не заменяет полноценный анализатор контейнера.

С LATM/LOAS AAC ситуация требует осторожности. В источниках периода развития DGAVCDec встречаются сообщения о добавлении поддержки определённых LATM-потоков, но справочные страницы 1.0.9 одновременно перечисляют AAC LATM/LOAS среди проблемных форматов. Для надёжной рабочей схемы это означает одно: если DGAVCIndex не извлекает аудио корректно, лучше демультиплексировать звук специализированным инструментом и использовать DGAVCDec только для видеодорожки.

Создание проекта DGA

После открытия нужного видео основной шаг — File → Save Project. В ряде сборок и связанных сценариев также встречается команда Save Project and Demux Video, когда вместе с индексом требуется получить элементарную видеодорожку. Для обычного frameserving достаточно DGA: повторное копирование видеопотока не даёт преимуществ, если исходник уже находится в подходящей форме.

Во время сохранения DGAVCIndex проходит по потоку и записывает данные индекса. На больших источниках это отдельная подготовительная операция, но она не эквивалентна полному декодированию и перекодированию каждого кадра. Размер DGA поэтому несопоставимо меньше результата рендера. Индексацию разумно выполнять один раз и повторно использовать проект во всех вариантах AviSynth-скрипта.

Название проекта лучше связывать с исходником: например, 00011_video.dga рядом с 00011.m2ts. В сложных проектах стоит явно указывать, какая дорожка использована, особенно если из одного контейнера извлечено несколько AVC-потоков. DGA не заменяет документацию рабочего процесса: спустя несколько недель одинаковые имена video.dga в разных папках легко перепутать.

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

Что хранит DGA и почему его нельзя отделять от исходника

DGA — текстово-индексное описание потока, в котором зафиксированы данные, необходимые DGAVCDecode для поиска и упорядочивания кадров. Он не содержит полноценную копию сжатой видеодорожки. Из этого следуют два практических правила: не удалять исходный AVC и не считать DGA переносимым самостоятельным видеофайлом.

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

Не стоит подменять исходник другим файлом того же имени. Даже если он визуально похож, смещение байтов, другая структура GOP или иной набор параметров делает старый индекс некорректным. Индекс должен соответствовать точному потоку, для которого был создан. Это особенно важно после ремонта TS, повторного remux или обрезки начала.

При архивировании рабочего проекта разумно сохранять вместе исходный elementary stream/TS, DGA и AVS. Аудио можно хранить отдельно. Такой набор позволяет воспроизвести цепочку без промежуточного lossless-рендера и понять, какие именно данные использовались на входе кодировщика.

Подключение DGAVCDecode.dll к AviSynth

Минимальный скрипт состоит из загрузки плагина и вызова источника:

LoadPlugin("C:\Tools\DGAVCDec\DGAVCDecode.dll")
AVCSource("D:\Project\movie.dga")

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

DGAVCDecode.dll должна соответствовать разрядности хоста AviSynth. Классический DGAVCDec распространялся как 32-разрядный плагин, поэтому типичный старый рабочий стек строился на 32-разрядных AviSynth и VirtualDub. На 64-разрядной системе это не мешает запускать 32-разрядные приложения, но 64-разрядный AviSynth-процесс не может напрямую загрузить 32-разрядную DLL. Ошибка вида не является приложением Win32 или код 193 часто указывает именно на несовпадение архитектур.

DGAVCDecode использует libavcodec. Важно не пытаться загружать libavcodec.dll через AviSynth как обычный плагин: это зависимость декодера, а не AviSynth-фильтр с экспортируемой функцией AVCSource. Если библиотека не найдена, нужно восстановить правильное расположение файлов из пакета DGAVCDec и убедиться, что Windows может разрешить зависимости DLL.

Параметр deblock в AVCSource

В реальных скриптах DGAVCDec встречается форма AVCSource("movie.dga", deblock=false). Этот параметр отключает встроенную H.264-деблокировку декодера. Использовать его следует не ради добавления резкости любой ценой, а с пониманием последствий: in-loop deblocking является частью стандартного процесса восстановления H.264 и влияет на предсказание последующих кадров.

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

Добавление аудио в AviSynth

Поскольку AVCSource() возвращает видео, аудио подключают отдельно. Для AC-3 часто применялся NicAudio, например:

video = AVCSource("movie.dga")
audio = NicAC3Source("movie PID 1100 DELAY -18ms.ac3")
AudioDub(video, audio)

Само имя файла в подобных рабочих процессах нередко содержит найденную задержку. Это полезная подсказка, но применять delay нужно осмысленно: знак и величина должны соответствовать тому, как звук был демультиплексирован. Двойное применение одного и того же смещения — сначала при извлечении, затем ещё раз в DelayAudio() — даст новую рассинхронизацию.

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

При изменении частоты кадров надо помнить о длительности. Команды вроде AssumeFPS, ChangeFPS, SelectEven и decimation по-разному воздействуют на число кадров и время. Если обработка меняет реальную длительность видео, аудио нужно синхронизировать с новой временной шкалой, а не просто подогнать единичной задержкой в начале.

Работа с прогрессивным, interlaced, PAFF и MBAFF AVC

H.264 способен кодировать прогрессивные кадры, чересстрочные поля и адаптивные комбинации полей и макроблоков. Для DGAVCDec это одна из наиболее чувствительных областей. В старых обсуждениях регулярно встречаются проблемные PAFF/MBAFF-потоки, особенно с AVCHD-камер и некоторыми вещательными TS, где декодирование через использовавшуюся версию libavcodec приводило к крупным блокам, ошибкам или неверной последовательности.

Первое правило — не деинтерлейсить по одному только ярлыку контейнера. Если источник маркирован как interlaced, нужно просмотреть движение покадрово и определить реальную структуру: полноценное 50i/60i, телесин, прогрессивное видео в interlaced-контейнере, смешанный материал или MBAFF. От этого зависит выбор TFM/TDecimate, Yadif, QTGMC и других методов.

Второе правило — отделять проблему source-фильтра от проблемы деинтерлейсера. Если уже на выходе чистого AVCSource() есть разрушенные макроблоки или неверный порядок кадров, последующий фильтр не исправит исходное декодирование. В таком случае нужно попробовать альтернативный источник — FFMS2, L-SMASH Works или DGDecNV для поддерживаемой конфигурации — и сравнить один и тот же проблемный фрагмент.

Третье правило — не использовать Forced Film как замену анализу. Film-происхождение, repeat flags и фактическая структура кадров — связанные, но не тождественные вещи. На смешанном материале лучше работать сегментами или выбирать фильтр, который принимает решения по содержимому, чем глобально навязывать один режим всей записи.

Частота кадров, pulldown и сохранение синхронизации

DGAVCDec оказывается в начале цепочки, поэтому ошибка в интерпретации кадровой частоты распространяется на весь последующий проект. Если исходник по содержанию является 23,976p, но поток сигнализирует повтор полей для 29,97, выбор honor/ignore pulldown влияет на количество выдаваемых временных позиций. На настоящем 59,94p попытка механически выбрать каждый второй кадр, наоборот, выбрасывает половину движения.

Надёжный подход — определить реальную временную структуру на коротком отрезке с движением. Нужно смотреть не только число, которое показывает программа, но и последовательность кадров: есть ли регулярные повторы, гребёнка, чередование полей, изменение рисунка на монтажных склейках. Только после этого имеет смысл применять TDecimate, SelectEven, AssumeFPS или другие преобразования.

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

Если в оригинальном TS были пропуски или нарушения временных меток, DGAVCIndex не всегда способен восстановить исходную трансляционную временную шкалу как современный контейнерный source-фильтр. Тогда нужно сравнивать длительность по независимому анализатору и, при необходимости, ремонтировать или remux-ить поток до индексации.

Случайный доступ и роль IDR/recovery points

В H.264 не каждый I-slice автоматически эквивалентен полностью независимой точке входа. Надёжный произвольный старт обычно связан с IDR или корректно обозначенной recovery point. Именно поэтому документация и описания DGAVCDec подчёркивают зависимость быстрого random access от частоты IDR-кадров или recovery point SEI.

На потоке с длинными открытыми GOP переход к случайной позиции может требовать декодирования значительного участка до целевого кадра. Это не дефект индекса как такового. Индекс сообщает, где находятся картинки и опорные структуры, но декодер всё равно обязан восстановить необходимые reference frames.

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

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

Командная строка и пакетная индексация

DGAVCIndex использовался не только интерактивно. В автоматизированных цепочках встречается запуск вида DGAVCIndex.exe -i "source.ts" -o "source.dga" -a -h -e. Такой формат применяли фронтенды вроде StaxRip и пакетные скрипты для массовой подготовки AVCHD. Он полезен, когда десятки однотипных клипов нужно проиндексировать без открытия каждого окна вручную.

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

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

Самый безопасный пакетный сценарий — сначала демультиплексировать или отобрать только AVC-источники, затем запустить индексацию, а кодирование ставить в очередь лишь после успешного открытия минимального AVS. Так легче локализовать сбой и не тратить часы на повторный проход большой очереди.

Подготовка Blu-ray M2TS

Для Blu-ray с AVC-видео DGAVCIndex способен открывать M2TS и создавать DGA напрямую. В типичном сценарии выбирают нужный файл из BDMV/STREAM, убеждаются, что отображается правильный кадр, при необходимости настраивают Audio Demux и выполняют Save Project. Полученный DGA подключается через AVCSource().

Главная сложность Blu-ray не в расширении M2TS, а в структуре диска. Полнометражный фильм может быть составлен из нескольких клипов плейлистом, иметь seamless branching, несколько ракурсов и повторно используемые сегменты. Открытие одного большого M2TS не всегда воспроизводит монтаж, заданный MPLS. DGAVCDec сам по себе не является анализатором плейлистов, поэтому сначала нужно определить правильную последовательность клипов.

Если фильм состоит из одного AVC-клипа, схема проста. Если плейлист многосегментный, разумнее сначала собрать корректную видеодорожку специализированным инструментом или использовать source-фильтр, понимающий нужную структуру. Механическое склеивание бинарных M2TS тоже не всегда безопасно из-за continuity counters, временных меток и особенностей транспорта.

При извлечении HD-аудио DGAVCIndex не должен быть единственным инструментом выбора. TrueHD, DTS-HD и дополнительные потоки удобнее анализировать специализированными средствами. В статье DGAVCDec рассматривается как AVC-indexer; сложную Blu-ray-аудиочасть лучше отделять от его основной задачи.

AVCHD с видеокамер

Камерные MTS/M2TS стали одним из характерных применений DGAVCDec, потому что H.264 из ранних AVCHD-камер было неудобно открывать в монтажных и кодировочных цепочках напрямую. Индексация позволяла получить DGA, а затем выполнять обработку в AviSynth. В учебных материалах того времени после AVCSource() часто добавляли деинтерлейсер и ресайз.

Но именно AVCHD наиболее ясно показывает ограничения старого декодера. Многие камеры записывали 1080i с PAFF/MBAFF, нестандартными сочетаниями метаданных и аудио, которые постоянно проверяли зрелость libavcodec. Если конкретный клип выдаёт крупные блоки, ломается на NAL-единице или неправильно перематывается, это не повод менять параметры x264: сначала нужно добиться корректного source decode.

Камерные записи также могут быть разбиты на множество MTS-файлов. DGAVCIndex 1.0.9 обычно ориентирован на работу с одним файлом за раз, поэтому автоматическая обработка пачки удобнее через командную строку или фронтенд. Если сегменты являются продолжением одной записи, объединять их следует способом, сохраняющим правильный транспортный порядок, а не простым монтажом уже после случайной обработки каждого клипа.

Для современных архивов AVCHD стоит сравнивать DGAVCDec с L-SMASH Works или FFMS2. Если альтернативный source-фильтр читает MTS напрямую и устойчиво выдаёт те же кадры, дополнительный DGA-проход может быть не нужен. DGAVCDec имеет смысл сохранять там, где существующий проект уже построен вокруг AVCSource() или требуется воспроизвести старую проверенную цепочку.

Работа с H.264 из MKV и MP4

DGAVCDec не предназначен для штатного открытия MP4 и MKV как контейнеров. Правильная последовательность — определить номер видеодорожки, извлечь AVC elementary stream без перекодирования, проиндексировать его DGAVCIndex и затем работать с DGA. Извлечение должно сохранять байты H.264, а не создавать новый encode.

У этого подхода есть цена: контейнерная информация о timestamps и некоторых аспектах временной шкалы остаётся за пределами элементарного потока. На обычном CFR-видео это часто не вызывает проблем, но для сложного VFR-материала современный индексатор контейнера значительно удобнее. FFMS2, например, строит собственный индекс и учитывает контейнерные временные метки.

Если MKV содержит AVC и обычный постоянный fps, извлечение может быть оправдано для совместимости с существующим скриптом AVCSource(). Если же внутри несколько сегментов, переменная частота, нестандартные timestamps или пользователь не хочет разделять звук и видео, переход на L-SMASH Works/FFMS2 обычно снижает количество ручных стадий.

Нельзя исправить неподдерживаемый MKV простым переименованием в .264. Контейнерные заголовки останутся внутри файла, и индексатор увидит не raw AVC, а чужую бинарную структуру. Демультиплексирование — отдельная операция, которая извлекает именно payload выбранной дорожки.

Фильтрация в AviSynth после AVCSource

После AVCSource() DGAVCDec фактически передаёт управление AviSynth. Дальше можно применять стандартные и внешние фильтры: crop, resize, deinterlace, denoise, inverse telecine, deband, subtitles и другие операции. Важно строить порядок фильтров с учётом природы источника, а не потому, что DGAVCDec требует конкретный набор.

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

Простой скрипт для прогрессивного источника может выглядеть так:

LoadPlugin("C:\Tools\DGAVCDec\DGAVCDecode.dll")
AVCSource("D:\Project\movie.dga")
Crop(0, 140, 0, -140)
Spline36Resize(1280, 528)

Для interlaced-видео между источником и resize ставят подходящий деинтерлейсер, параметры которого выбирают после анализа порядка полей. В старых руководствах встречается Yadif; сегодня могут использоваться более сложные методы. Это уже область AviSynth-фильтрации и не является встроенной функцией DGAVCDec.

Кодирование после DGAVCDec

AVS-скрипт можно подать кодировщику, который поддерживает AviSynth-вход. Исторически DGAVCDec часто использовался с x264, MeGUI, VirtualDub и MPEG-2-кодировщиками. Сам DGAVCDec не задаёт битрейт, профиль, GOP, B-frames или контейнер результата. Все параметры конечного кодека выбираются в следующем звене.

Это разделение полезно для диагностики. Если AVCSource() открывается и кадры правильные, но финальный файл имеет блоки или неправильный цвет, проблема может находиться в фильтрации, цветовой конверсии или кодировщике. Если артефакт уже виден в чистом источнике, бессмысленно менять CRF или preset.

Для MPEG-2 DVD типичная старая цепочка была: DGAVCIndex → DGA → AVCSource → resize до DVD-разрешения → MPEG-2 encoder. Для H.264-рекодирования: DGA → фильтрация → x264. В обоих случаях DGAVCDec обеспечивает только чтение AVC, а не формат конечного файла.

При выводе в контейнер звук и видео обычно кодируются/копируются отдельно и затем мультиплексируются. Так проще сохранить оригинальный AC-3 без лишней потери или выбрать другой аудиокодек независимо от видеопроцесса.

Ограничение POC и почему оно важно

В описании ограничений DGAVCDec 1.0.9 указывается поддержка только определённого типа picture order count, прежде всего POC type 0. POC — механизм H.264, который помогает восстановить порядок отображения картинок, отличающийся от порядка декодирования при B-кадрах. Если поток использует неподдерживаемый вариант, индексатор/декодер может неверно упорядочить кадры либо вообще отказаться работать.

Пользователь обычно не выбирает POC type в интерфейсе. Это свойство закодированного потока, заданное энкодером. Поэтому исправить несовместимость галочкой нельзя. Если анализатор показывает, что проблемный файл создан с другой структурой POC и DGAVCDec не справляется, практический выход — использовать другой source-фильтр.

Это хороший пример того, почему DGAVCDec не следует рассматривать как универсальный современный H.264-reader. Он точечно решает свою задачу для совместимых потоков, но H.264 допускает множество комбинаций параметров. Современные FFmpeg/L-SMASH-based источники охватывают их шире.

Если необходимо воспроизвести старый проект, который ранее успешно работал с тем же DGA и тем же бинарным набором, менять source-фильтр без причины не нужно. Но для нового неизвестного потока полезно заранее иметь альтернативу, а не пытаться насильно подогнать любой H.264 под ограничения DGAVCDecode.

Зависимость от libavcodec

DGAVCDecode опирается на libavcodec для декодирования AVC. Это означает, что качество поддержки конкретного профиля и особенностей битстрима ограничено версией библиотеки, с которой поставлялась программа. В период DGAVCDec H.264-декодер FFmpeg активно развивался, и некоторые PAFF/MBAFF или необычные NAL-структуры обрабатывались хуже, чем в современных сборках.

Если один и тот же файл корректно декодируется современным FFmpeg, но ломается в DGAVCDec, это не противоречие. Между реализациями прошли годы исправлений. Для диагностики полезно сравнить проблемный кадр в альтернативном source-фильтре, основанном на более новой библиотеке.

Ошибку отсутствующей libavcodec.dll следует устранять на уровне файлов пакета. Попытка LoadPlugin("libavcodec.dll") в AVS ошибочна: AviSynth ожидает DLL с интерфейсом плагина, а libavcodec — библиотека кодеков. DGAVCDecode должен найти её как зависимость обычным механизмом загрузчика Windows.

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

Типичные ошибки и способы решения

AVCSource: could not load one of the input files

Сначала проверяют, существует ли исходный AVC/TS, на который ссылается DGA. Затем — не перемещался ли файл после индексации. Если проект создан из временного elementary stream, а фронтенд удалил его после предыдущего задания, нужно повторно извлечь видео и создать новый DGA.

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

AviSynth не видит функцию AVCSource

Такое сообщение означает, что DGAVCDecode.dll не загружена. Проверяют путь в LoadPlugin(), разрядность AviSynth и саму DLL. Если используется автоматический plugins-каталог, временно лучше прописать абсолютный LoadPlugin, чтобы исключить неправильную папку автозагрузки.

Если LoadPlugin сообщает код 193 или not a valid Win32 application, почти всегда нужно привести к одной архитектуре хост, AviSynth и плагин. Для классического DGAVCDec это обычно 32-разрядная цепочка.

Ошибка libavcodec.dll

Не добавляйте libavcodec в AVS. Верните библиотеку из той же поставки DGAVCDec и держите связанные DLL там, где их ожидает DGAVCDecode. Случайная новая libavcodec с интернета не является совместимой заменой по умолчанию.

Если пакет находится в каталоге с ограниченными правами, перенесите его в простой путь вроде C:\Tools\DGAVCDec. Это одновременно упрощает диагностику путей и исключает виртуализацию/блокировку старых DLL в защищённых директориях.

DGAVCIndex открывает файл, но в середине появляются большие блоки

Проверьте тот же фрагмент современным FFmpeg-based source-фильтром. Для старого libavcodec известны сложности с некоторыми interlaced AVC. Если дефект отсутствует в FFMS2/L-SMASH Works, дальнейшие фильтры DGAVCDec не исправят ошибку декодирования — лучше сменить источник.

Если дефект воспроизводится везде, возможно повреждён сам транспортный поток. Тогда стоит remux-ить или ремонтировать TS и после этого заново создать DGA, потому что старый индекс соответствует прежнему байтовому расположению.

Неверная частота кадров

Сравните показания DGAVCIndex с MediaInfo/ffprobe и покадровой картиной. Для материала с repeat flags простое число fps без анализа может вводить в заблуждение. Проверьте Field Operation и не применяйте Forced Film автоматически.

Если поток VFR или опирается на контейнерные timestamps, извлечение raw H.264 может лишить вас части временной информации. В таком случае FFMS2 или L-SMASH Works зачастую лучше подходит, потому что индексируется контейнер, а не только elementary stream.

Звук постепенно уходит от видео

Постепенный drift обычно не лечится постоянным DelayAudio. Он указывает на расхождение длительности: неверный fps, удалённые/добавленные кадры, VFR или потерянные timestamps. Сначала сравните длительность исходника и обработанного видеоклипа.

Если вы применяли AssumeFPS, убедитесь, что понимаете изменение скорости. Если применялась decimation, проверьте, удаляются ли только реальные дубликаты. Начальный delay исправляет только постоянный сдвиг, но не разницу скорости.

Аудио не обнаруживается в TS

Проверьте PID и формат дорожки внешним анализатором. DGAVCIndex может не поддерживать конкретный аудиоформат или вариант упаковки. В этом случае демультиплексируйте аудио отдельно, оставив DGAVCDec только видеозадачу.

Для многоканальных Blu-ray форматов отдельный демультиплексор предпочтительнее даже при успешном обнаружении: так проще выбрать core, lossless extension или нужный язык без двусмысленности.

Скрипт работает в одном приложении и не работает в другом

Чаще всего различается разрядность. 32-разрядный VirtualDub и 64-разрядный кодировщик видят разные AviSynth-окружения и наборы plugins. Нужно проверить не Windows 64-bit вообще, а конкретную архитектуру каждого процесса.

Вторая причина — разные текущие каталоги и относительные пути. Используйте абсолютные пути к DGAVCDecode.dll и DGA, пока цепочка не станет стабильной.

После перемотки кадр неправильный, а при последовательном просмотре нормальный

Это может быть связано с редкими IDR/recovery points или особенностями seeking. Проверьте, повторяется ли проблема в одном и том же месте, и сравните с альтернативным source-фильтром. Для финального последовательного encode дефект может не возникать, но для монтажной навигации такая нестабильность является весомым ограничением.

DGAVCIndex не открывает MP4/MKV

Это ожидаемое ограничение. Извлеките AVC-дорожку без перекодирования или используйте source-фильтр, умеющий индексировать контейнер напрямую. Переименование расширения не помогает.

После remux старый DGA перестал работать

Это нормальная ситуация: байтовая структура источника изменилась. Создайте DGA заново. Индекс нельзя считать универсальным для разных контейнерных копий одного и того же визуального материала.

Практические сценарии

Сценарий 1: M2TS с AVC и AC-3 для перекодирования

  1. Открыть M2TS через File → Open.
  2. Проверить, что показывается нужная AVC-дорожка.
  3. Через Audio → Audio Demux выбрать AC-3, если DGAVCIndex корректно его видит.
  4. Сохранить DGA через File → Save Project.
  5. Создать AVS с LoadPlugin и AVCSource.
  6. Добавить необходимые фильтры.
  7. Закодировать видео, затем смультиплексировать его с аудио.

Главное преимущество схемы — отсутствие промежуточного lossless AVI. Кадры декодируются по запросу кодировщика, а исходный AC-3 может остаться без повторного сжатия.

Сценарий 2: H.264 из MKV

Сначала из MKV извлекается именно видеодорожка AVC. Полученный .h264 открывается в DGAVCIndex и индексируется. Аудио остаётся отдельным. Такой путь оправдан, если существующая обработка уже написана под AVCSource и контейнер имеет обычную постоянную временную структуру.

Если MKV содержит VFR, сложные timestamps или пользователь хочет минимизировать подготовительные операции, лучше сразу использовать FFMS2/L-SMASH Works. DGAVCDec здесь добавляет ручной demux без заметного выигрыша.

Сценарий 3: диагностика повреждённого TS

Откройте TS напрямую. Если DGAVCIndex падает, извлеките видеопоток и повторите. Если elementary stream работает, remux исходного транспорта может решить проблему. Если не работает и raw AVC, сравните с современным декодером и определите, повреждён ли битстрим или это ограничение DGAVCDecode.

После любого ремонта поток индексируется заново. Использование старого DGA после изменения входного файла делает диагностику бессмысленной.

Сценарий 4: подготовка к покадровой фильтрации

Создайте DGA, затем минимальный AVS без фильтров. Откройте его в просмотрщике AviSynth и найдите несколько контрольных кадров. После этого по одному добавляйте crop, deinterlace/IVTC, resize и другие операции. Такой порядок позволяет точно понять, на каком этапе появляется проблема.

Сценарий 5: пакет из камерных MTS

Для множества независимых клипов можно использовать командную строку DGAVCIndex. Имена DGA формируются из имён исходников, а AVS создаются шаблоном. Перед полным encode полезно открыть хотя бы начало каждого скрипта, потому что один клип с отличающимся профилем AVC способен остановить всю очередь.

Когда DGAVCDec действительно удобен

Программа особенно уместна в старых AviSynth-проектах, где уже есть DGA и проверенные скрипты с AVCSource(). Замена source-фильтра в таком проекте может изменить порядок кадров, цветовой тракт, поведение seek или даже число кадров, что нежелательно при воспроизводимости архивного encode.

Второй удачный случай — простой AVC elementary stream, для которого нужен покадровый источник без DirectShow. Здесь DGAVCIndex выполняет именно ту задачу, для которой создан: один раз индексирует поток и затем предоставляет быстрый доступ через DGA.

Третий случай — старые TS/M2TS, которые DGAVCIndex стабильно понимает и из которых одновременно удобно извлечь простой AC-3. При такой совместимости цепочка остаётся компактной: open, audio demux, save project, AVCSource.

Но если материал новый, контейнер сложный или требования включают 10-bit AVC, необычные POC, современный HDR-пайплайн и широкий набор контейнеров, DGAVCDec не должен быть выбором по привычке. Его ценность — предсказуемость в узком поддерживаемом диапазоне, а не универсальность.

Когда лучше выбрать другой source-фильтр

FFMS2 обычно удобнее, когда нужно индексировать MP4, MKV и множество других контейнеров без предварительного demux. Он также основан на FFmpeg, но современные сборки используют значительно более зрелые декодеры и лучше подходят для потоков, которые старый DGAVCDecode обрабатывает с ошибками.

L-SMASH Works особенно полезен для MP4/MOV и LibavSMASH/LWLibavVideoSource-сценариев. Он позволяет работать с контейнером напрямую и хорошо вписывается в современные AviSynth+ цепочки. При необходимости точного frame serving это более естественная замена для новых проектов.

DGDecNV предназначен для другой технической модели: индексирование и декодирование через семейство DGTools с аппаратным ускорением NVIDIA в поддерживаемых конфигурациях. Он ближе всего по философии индекс + source-фильтр, но имеет собственные требования и формат проекта.

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

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

ПрограммаЛучше подходит дляГлавное ограничение
DGAVCDecAVC/H.264 elementary stream и TS/M2TS с выдачей через AVCSourceУзкая поддержка контейнеров и старый libavcodec
DGDecNVИндексирование MPEG-2/AVC/VC-1 в DGTools-сценариях с совместимым NVIDIA GPUЗависимость от поддерживаемой аппаратной конфигурации и собственной экосистемы
FFMS2Универсальное индексирование MP4, MKV, TS и других форматов в AviSynthПоведение временных меток и выбор треков требуют понимания параметров FFMS2
L-SMASH WorksСовременное чтение MP4/MOV и многих контейнеров через AviSynthДля некоторых потоков выбор между L-SMASH и LWLibav источниками неочевиден новичку
DirectShowSourceБыстрое открытие файла через установленные системные фильтрыРезультат зависит от сплиттеров и декодеров в конкретной Windows

Практический вывод прост: DGAVCDec стоит выбирать, если у вас совместимый AVC-поток и нужна именно классическая схема DGAVCIndex → DGA → AVCSource. Для нового проекта с MP4/MKV или сложным H.264 удобнее начинать с L-SMASH Works либо FFMS2. DGDecNV ближе к DGAVCDec по идее индексирования, но это уже другой стек и другие требования. DirectShowSource полезен как быстрый обходной путь, но хуже подходит для полностью воспроизводимой цепочки.

Ограничения, о которых стоит знать до начала работы

  • DGAVCDec не является универсальным контейнерным reader для MP4/MKV.
  • Проект DGA зависит от исходного файла и не заменяет его.
  • Классический DGAVCDecode рассчитан на 32-разрядную AviSynth-цепочку.
  • Совместимость с interlaced PAFF/MBAFF потоками ограничена возможностями старого libavcodec.
  • В описании 1.0.9 отдельно указывается ограничение по POC type.
  • Быстрый random access зависит от IDR/recovery points в самом потоке.
  • Аудиодемультиплексирование охватывает не все современные варианты звука.
  • AVCSource возвращает видео; сложная обработка и кодирование находятся вне DGAVCDec.

Эти ограничения не делают программу бесполезной. Они просто задают точную область применения. Если вход соответствует ожиданиям DGAVCDec, индексатор остаётся компактным и понятным инструментом. Проблемы начинаются, когда его пытаются использовать как замену современному универсальному FFmpeg-based source-фильтру.

Как организовать папки проекта

Для ручной работы удобно выделить папку source под исходные TS/M2TS или raw AVC, index под DGA, script под AVS и audio под демультиплексированные дорожки. Если DGA хранит абсолютный путь к исходнику, такая структура должна оставаться неизменной до завершения кодирования.

Сам DGAVCDec лучше держать в коротком каталоге вроде C:\Tools\DGAVCDec. Это упрощает LoadPlugin и снижает число проблем с правами старых приложений. Пакет DLL не стоит смешивать с случайными версиями libavcodec от других программ.

В AVS удобно первым блоком размещать только source-строки, затем отдельными группами — temporal-фильтры, crop/resize, цветовые преобразования и финальные ограничения. Тогда при диагностике источник можно проверить, закомментировав всё после AVCSource.

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

Проверка корректности перед долгим encode

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

Затем добавьте только temporal-обработку — деинтерлейс или IVTC — и повторите проверку. После этого подключайте crop/resize. Разделение этапов помогает не спутать артефакт source decode с ошибкой фильтра.

Сравните число кадров и длительность с ожиданием. Если после выбора field operation или decimation длительность изменилась, это должно быть осознанным результатом. Синхронизацию аудио проверяют не только в начале, но и ближе к концу.

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

Разбор частых заблуждений

DGA — это конвертированный видеофайл

Нет. Это индекс. Само видео остаётся в исходном AVC/TS. Поэтому DGA создаётся быстро и занимает мало места, но без исходника не воспроизводится.

Если DGAVCIndex показывает кадр, значит кодирование точно пройдёт

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

Любой MP4 с H.264 можно просто открыть DGAVCIndex

Нет. H.264 — видеокодек, MP4 — контейнер. DGAVCDec ориентирован на raw AVC и транспортные потоки; MP4 обычно нужно демультиплексировать либо открыть другим source-фильтром.

Honor Pulldown Flags всегда правильнее Ignore

Не всегда. Выбор зависит от структуры конкретного материала и желаемой временной последовательности. Автоматическое применение одного режима ко всем источникам ошибочно.

Forced Film превращает interlaced в progressive

Нет. Это не полноценный деинтерлейсер. На настоящем interlaced-видео требуется отдельная обработка полей.

libavcodec.dll надо добавить через LoadPlugin

Нет. Загружается DGAVCDecode.dll; libavcodec является его зависимостью и должна быть совместимой версией из соответствующего набора.

На 64-bit Windows нужен 64-bit DGAVCDecode

Не обязательно. 32-разрядные приложения работают в 64-разрядной Windows. Важно, чтобы разрядность AviSynth-хоста и плагина совпадала.

Использование с VirtualDub и другими просмотрщиками

VirtualDub часто применялся как удобный способ открыть AVS и проверить кадры. Для DGAVCDec принципиально, чтобы VirtualDub использовал ту же разрядность, что и AviSynth и DGAVCDecode. 32-bit VirtualDub на 64-bit Windows — нормальная комбинация для классического плагина.

В VirtualDub можно быстро перейти к сцене, оценить crop и сохранить тестовый участок. Но если seek вызывает зависания, не следует сразу обвинять VirtualDub: источник H.264 с редкими IDR может сам требовать долгого восстановления reference frames. Сравнение последовательного воспроизведения помогает понять разницу.

MeGUI и StaxRip исторически умели автоматизировать создание DGA и AVS. При чтении старых инструкций нужно учитывать, что конкретные версии фронтендов позже переходили на другие индексаторы. Поэтому пункты меню современного MeGUI не являются частью DGAVCDec и не должны использоваться как описание его собственных функций.

Любое приложение после AVS видит уже результат AviSynth. Оно не обязано знать, что источником был DGAVCDec. Это делает связку удобной: source-фильтр можно заменить, сохранив остальную часть скрипта, если новый источник выдаёт совместимую последовательность кадров.

Качество изображения и отсутствие лишнего перекодирования

Индексация сама по себе не ухудшает качество. DGAVCIndex не создаёт новый сжатый видеопоток при обычном Save Project, а DGAVCDecode декодирует исходный AVC в кадры для AviSynth. Потери появляются только на последующем этапе, если результат снова кодируется с потерями.

Нельзя, однако, говорить, что любой декодер без потерь эквивалентен другому при наличии ошибок реализации. Теоретически корректный H.264 decode детерминирован, но старый libavcodec мог неверно обработать определённый поток. Поэтому визуальная идентичность на совместимом файле не отменяет необходимость проверки сложных PAFF/MBAFF случаев.

При сохранении BMP/PNG для сравнения дополнительным источником расхождений становится YUV→RGB. Это уже не H.264 decoding как таковой, а преобразование цветового пространства. Для технического сравнения полезнее сопоставлять YUV-плоскости либо применять одинаковую матрицу RGB-конверсии.

Если конечная цель — уменьшить размер файла, качество определяет в первую очередь последующий кодировщик и параметры фильтрации. DGAVCDec обеспечивает доступ к источнику, но не выбирает CRF, bitrate, preset или psycho-visual настройки.

Работа с обрезкой и выбором участка

DGAVCIndex имеет навигацию, пригодную для определения интересующего участка, но точный монтаж с внутренними разрезами не является его основной задачей. Для frame-accurate обработки проще открыть DGA в AviSynth и применить Trim(), потому что тогда границы задаются уже в декодированной кадровой последовательности.

Например, Trim(1000, 5000) возвращает нужный диапазон кадров после AVCSource(). Это не переписывает исходный H.264; кодировщик получает только выбранный сегмент. Для нескольких фрагментов AviSynth позволяет объединять клипы, но при сложном монтаже удобнее использовать NLE.

Если требуется физически вырезать кусок H.264 без перекодирования, это другая задача. Из-за GOP и reference frames точная обрезка elementary stream сложнее простой работы с DGA. DGAVCDec не следует использовать как lossless H.264 cutter.

При анализе проблем полезно использовать короткий Trim вокруг дефекта и кодировать только этот участок. Так можно быстро сравнить DGAVCDec и альтернативный source-фильтр без обработки всего фильма.

Цветовое пространство и уровни

DGAVCDec передаёт декодированное видео в AviSynth, а дальнейшие цветовые преобразования зависят от скрипта. Если конечный фильтр или кодировщик принимает YUV, нет причины переводить материал в RGB только потому, что экран DGAVCIndex показывает RGB-превью.

При переходе в RGB необходимо правильно выбрать матрицу для SD/HD источника и понимать диапазон уровней. Ошибка Rec.601/Rec.709 или TV/full range приводит к изменению оттенков и контраста, которое затем ошибочно приписывают декодеру. Это особенно заметно при сравнении Blu-ray кадров.

Обрезка и ресайз в YUV обычно сохраняют более прямой тракт для видеокодирования. RGB нужен в основном фильтрам, которые работают только в этом пространстве. После них необходимо корректно вернуться в формат, который ожидает энкодер.

DGAVCDec не является системой управления цветом и не интерпретирует современные HDR-метаданные как отдельный рабочий процесс. Если проект требует точной обработки HDR10, динамических метаданных или 10-bit pipeline, нужно выбирать современные инструменты, сохраняющие соответствующую разрядность и сигнализацию.

Почему DGAVCDec не стоит путать с DGMPGDec и DGDecNV

DGMPGDec/DGIndex обслуживает прежде всего MPEG-1/2 и создаёт D2V, который открывается функцией MPEG2Source(). DGAVCDec работает с AVC/H.264, создаёт DGA и использует AVCSource(). Похожие названия и интерфейс не делают проекты взаимозаменяемыми.

DGDecNV относится к другой линии инструментов с собственным индексатором и функцией source. Он поддерживает больше кодеков и задействует совместимое аппаратное декодирование NVIDIA. DGI нельзя автоматически подставить в AVCSource, а DGA — в DGSource.

При переносе старого скрипта важно сохранить правильную пару индекс + DLL + функция. Ошибка вида попытки открыть D2V через AVCSource или DGA через MPEG2Source не является вопросом параметров — это разные форматы проекта.

В таблицах и каталогах названия иногда перечисляются рядом, поэтому при поиске скриншотов и инструкций нужно сверять заголовок окна. Для DGAVCDec нас интересует именно DGAVCIndex и DGAVCDecode.dll, а не внешне похожий DGIndex для MPEG-2.

Рекомендации по воспроизводимой цепочке

Используйте фиксированный набор бинарников DGAVCDec и не заменяйте libavcodec отдельно. Храните его вместе с проектом или хотя бы записывайте используемую сборку. Старые плагины чувствительны к несовместимым DLL, и обновление одной библиотеки часто ухудшает воспроизводимость.

Сохраняйте исходный AVC/TS неизменным после индексации. Любой remux, repair или trim должен сопровождаться новым DGA. Это базовое правило, которое устраняет большую часть труднообъяснимых ошибок.

Пишите AVS так, чтобы source-блок был отделён от фильтров. Тогда можно быстро заменить AVCSource() на альтернативу и сравнить кадры. Для спорных interlaced источников это особенно полезно.

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

Если DGAVCDec стабильно открывает конкретный тип вашего материала, нет необходимости усложнять проект. Но если появляются ошибки декодирования, не пытайтесь исправлять их последующими фильтрами: смените source-фильтр и продолжайте обработку уже с корректных кадров.

Разбор ошибок NALU и повреждённых битовых потоков

H.264 состоит из NAL-единиц разных типов: одни несут параметры последовательности и картинки, другие — срезы кадра, SEI и служебную информацию. DGAVCIndex должен последовательно разобрать эти блоки, чтобы построить индекс. Сообщение о неизвестном или неожиданном NALU не всегда означает, что весь файл безнадёжно повреждён: часть служебных единиц можно пропустить, но для конкретной старой версии парсера неизвестный тип способен нарушить дальнейшую синхронизацию.

Если появляется сообщение вроде Found NALU Type ... undefined с возможностью продолжить, сначала нужно понять, воспроизводится ли ошибка в одном месте и повреждаются ли после неё кадры. Не следует автоматически нажимать Ignore для длинной очереди. Один проблемный NAL может быть безвредным служебным блоком, а может указывать на поток, структура которого не поддерживается конкретным DGAVCIndex.

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

Для TS ошибки могут появляться ещё до уровня H.264: потерянные транспортные пакеты, неправильные continuity counters, битая PAT/PMT или разрыв PCR/PTS. Ремультиплексирование иногда устраняет контейнерную часть проблемы, но после любого такого изменения DGA создаётся заново. Нельзя ремонтировать TS и продолжать пользоваться индексом, построенным по старому бинарному расположению.

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

Как работать с PID в транспортном потоке

В MPEG-TS каждая элементарная дорожка передаётся под своим PID. В простом файле может быть один AVC PID и один AC-3 PID, но вещательные записи часто содержат несколько программ, языков и служебных потоков. Если DGAVCIndex выбирает не ту дорожку, итоговый DGA может относиться к второстепенному видео или вообще не соответствовать ожидаемому материалу.

Перед индексацией сложного TS разумно получить список программ и PID независимым анализатором. Затем в DGAVCIndex нужно убедиться, что кадр, размеры и содержимое относятся к нужному сервису. Для аудио особенно важно сверить формат и язык: два соседних AC-3 PID могут быть основной дорожкой и аудиодескрипцией.

Когда транспорт содержит много мусора или несколько программ, предварительный remux только нужных PID часто делает работу стабильнее. Это не перекодирование: видеобитстрим сохраняется, а контейнер переписывается с более простой структурой. После remux создаётся новый DGA, потому что ссылки старого проекта на байтовые позиции уже недействительны.

Если DGAVCIndex видит видео, но не видит ожидаемый звук, это не мешает использовать его для DGA. Аудио можно извлечь отдельным демультиплексором по известному PID. Такой раздельный путь часто лучше, чем попытка заставить DGAVCIndex обслуживать формат звука, который он распознаёт нестабильно.

Для Blu-ray PID обычно более предсказуемы, но M2TS содержит дополнительный 4-байтовый timestamp prefix перед 188-байтовыми TS-пакетами. В DGAVCDec 1.0.9 отдельно исправлялась обработка M2TS, поэтому проблемы со старой сборкой могут проявляться именно на таких файлах. Если используется 1.0.9, имеет смысл держать весь комплект бинарников вместе, а не смешивать EXE и DLL из разных выпусков.

Проверка исходника до индексации

DGAVCDec лучше всего работает, когда вход заранее классифицирован. Перед запуском полезно знать кодек, профиль, level, размеры, частоту кадров, scan type, число референсов, контейнер и наличие нескольких программ. Это позволяет сразу понять, соответствует ли файл обычному сценарию AVCSource или потребует альтернативы.

Особенно важен профиль interlaced. Маркировка Scan type: Interlaced ещё не описывает, как именно закодированы поля. MBAFF разрешает переключать режим на уровне макроблоков, PAFF — на уровне picture. Старый libavcodec в DGAVCDec не одинаково хорошо справлялся со всеми комбинациями, поэтому сведения анализатора нужно дополнять реальным покадровым просмотром.

Полезно также проверить, нет ли в исходнике переменной частоты. Elementary H.264 сам по себе не несёт все те контейнерные timestamps, которыми располагает MKV или MP4. Если временная шкала сложная, извлечение raw потока ради DGAVCDec может упростить данные слишком сильно. Для такого материала индексатор контейнера предпочтительнее.

Размер кадра и SAR следует различать. AVC может хранить 1440×1080 с SAR, который при отображении даёт 1920×1080. Если бездумно сделать resize только по числу пикселей, изображение станет геометрически неверным. DGAVCIndex способен показывать frame size и display-related данные, но окончательное решение о resize должно учитывать SAR/DAR.

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

Производительность и потребление ресурсов

DGAVCIndex выполняет индексацию заметно быстрее полного перекодирования, потому что не создаёт новый видеопоток. Тем не менее ему нужно пройти исходник и разобрать его структуру. На медленном диске большие Blu-ray M2TS могут индексироваться дольше из-за чтения десятков гигабайт, даже если нагрузка CPU сравнительно умеренная.

Последующее декодирование через AVCSource выполняется процессором и зависит от сложности H.264. High Profile 1080p с большим числом референсов тяжелее простого 720p. Параметры downstream-фильтров часто влияют на скорость сильнее самого source-фильтра: QTGMC, тяжёлый denoise и высококачественный resize могут стать главным узким местом.

Random seek обычно дороже последовательного чтения. Если приложение постоянно прыгает между удалёнными кадрами, декодеру приходится восстанавливать reference chain от доступной точки входа. Поэтому производительность интерактивного предпросмотра нельзя напрямую переносить на скорость линейного encode.

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

Диск с DGA не обязан быть быстрым: сам индекс небольшой. Критичен доступ к исходному AVC/TS. Если он лежит на медленном сетевом ресурсе, seek и повторные проходы будут заметно тяжелее. Для стабильного кодирования лучше работать с локальной копией исходника и сохранять неизменный путь.

Примеры AviSynth-скриптов для разных задач

Чистый прогрессивный источник

LoadPlugin("C:\Tools\DGAVCDec\DGAVCDecode.dll")
AVCSource("D:\Work\source.dga")

Такой скрипт нужен для первичной диагностики. Пока он не открывается без ошибок, не следует добавлять resize, denoise или кодировщик. Минимальная цепочка показывает, способен ли DGAVCDecode корректно вернуть кадры.

Прогрессивный источник с обрезкой и масштабированием

LoadPlugin("C:\Tools\DGAVCDec\DGAVCDecode.dll")
AVCSource("D:\Work\source.dga")
Crop(0, 132, 0, -132)
Spline36Resize(1280, 544)

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

Interlaced-видео с отдельным деинтерлейсером

LoadPlugin("C:\Tools\DGAVCDec\DGAVCDecode.dll")
AVCSource("D:\Work\camera.dga")
# Далее подключается выбранный deinterlace-фильтр
# и только после него выполняется resize.

Смысл примера в порядке операций. DGAVCDec не должен превращаться в источник готового progressive только из-за выбора Field Operation. Настоящий deinterlace остаётся отдельной стадией.

Видео плюс AC-3

LoadPlugin("C:\Tools\DGAVCDec\DGAVCDecode.dll")
LoadPlugin("C:\Tools\NicAudio\NicAudio.dll")
v = AVCSource("D:\Work\movie.dga")
a = NicAC3Source("D:\Work\movie.ac3")
AudioDub(v, a)

Если у AC-3 есть известный delay, его применяют один раз в правильном месте цепочки. В производственном проекте удобнее хранить значение задержки в заметке или имени дорожки, чем пытаться вспомнить его при финальном mux.

Перенос старого проекта на новый source-фильтр

Иногда DGAVCDec нужен только потому, что старый AVS начинается с AVCSource(), но конкретный H.264 больше не декодируется надёжно. Тогда можно заменить только источник, оставив последующие фильтры. Однако перед этим необходимо сравнить число кадров, fps, порядок кадров и цветовое пространство.

FFMS2 может выглядеть так: FFVideoSource("source.mkv") или через обёртку FFmpegSource2. L-SMASH Works использует свои функции source. Эти фильтры могут по-другому интерпретировать timestamps, поэтому формальное открытие того же визуального материала ещё не гарантирует идентичную нумерацию кадров.

Для скрипта с Trim(54516,58832) даже сдвиг на один кадр имеет значение. Поэтому сначала находят несколько контрольных кадров по содержимому, сверяют их номера и только потом переносят монтажные точки. Если старый DGA открывается хотя бы на части файла, он может служить эталоном для сравнения.

При interlaced/telecine материале нужно отдельно сверить field order и влияние pulldown flags. Один source может уже выдавать последовательность с учётом repeat flags, другой — сырые coded frames. В результате старый TDecimate-скрипт после замены источника может удалять не те кадры.

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

Как выбрать между DGAVCDec, FFMS2 и L-SMASH Works

Выбор можно свести к нескольким вопросам. Если вход — raw H.264 и существующий AviSynth-проект уже использует AVCSource, DGAVCDec остаётся естественным решением. Если вход — MKV/MP4 и нет причины демультиплексировать его вручную, FFMS2 или L-SMASH Works обычно удобнее.

Если источник interlaced AVC и DGAVCDec показывает макроблоки или ломает кадры, приоритетом становится современный декодер. Если же FFMS2 неверно обрабатывает специфическую временную шкалу, а DGAVCDec на raw stream выдаёт стабильную картину, можно предпочесть DGA, но затем отдельно решить вопрос синхронизации.

Для MP4/MOV L-SMASH Works часто даёт прямой и предсказуемый путь через контейнер. Для широкого набора контейнеров FFMS2 удобен своей универсальностью и собственным индексом. DGAVCDec выигрывает не широтой, а простотой классической схемы и совместимостью со старыми скриптами.

ВопросПредпочтительный вариант
Есть готовый DGA и проверенный AVSDGAVCDec
Новый MKV/MP4 без сложной наследуемой цепочкиFFMS2 или L-SMASH Works
Raw .264 с обычным POC и стабильным декодированиемDGAVCDec подходит
Проблемный PAFF/MBAFFСначала проверить современный source
Нужны контейнерные timestamps/VFRИндексировать контейнер, а не raw AVC
Требуется повторить старый encode кадр-в-кадрСохранить исходный DGA-стек

Практика восстановления старой рабочей среды

Если сохранился AVS, но потеряна программа, сначала смотрят, какую функцию source он вызывает. Для AVCSource() нужен именно DGAVCDecode.dll и соответствующий DGA. Наличие только AviSynth недостаточно. Если DGA отсутствует, его можно создать заново только при наличии оригинального AVC/TS.

Когда AVS ссылается на старый абсолютный путь, лучше восстановить каталог либо исправить путь и заново проверить контрольные кадры. Для DGA путь к исходнику также может потребовать восстановления. Иногда быстрее воссоздать индекс в новой папке, чем вручную редактировать внутреннее содержимое проекта.

Старую 32-bit цепочку можно запускать и на 64-bit Windows, если использовать 32-bit AviSynth-хост. Не следует смешивать 64-bit плагины с 32-bit процессом. Если современный кодировщик существует только в 64-bit варианте, проще вывести кадры через подходящий bridge или заменить source-фильтр, чем пытаться загрузить DGAVCDecode непосредственно в несовместимый процесс.

При восстановлении не нужно обновлять каждую DLL по отдельности. Ценность старого проекта как раз в известной комбинации компонентов. Изменение libavcodec, DGAVCDecode и AviSynth одновременно делает невозможным понять, что стало причиной отличий.

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

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

Программа не кодирует видео в H.264, HEVC, AV1 или MPEG-2. Она также не выбирает CRF, bitrate и preset. Эти параметры относятся к кодировщику, который получает кадры после AviSynth.

DGAVCDec не является полноценным muxer/demuxer для всех контейнеров. Audio Demux — вспомогательная возможность для распознанных транспортных потоков, а не замена современному инструменту работы с Blu-ray, Matroska или MP4.

DGAVCDec не выполняет качественный универсальный deinterlace одним переключателем. Field Operation влияет на интерпретацию флагов, но настоящий deinterlace/IVTC выполняется фильтрами AviSynth.

Программа не восстанавливает потерянные кадры из повреждённой трансляции и не исправляет битый H.264 автоматически. Remux может убрать контейнерные проблемы, но повреждение payload остаётся повреждением.

Наконец, DGAVCDec не сохраняет современную HDR-метаинформацию как отдельный управляемый объект и не строит 10/12-bit workflow. Для таких задач нужен другой стек, рассчитанный на современную глубину цвета и метаданные.

Save Project и Save Project and Demux Video: когда нужен каждый вариант

Для обычной AviSynth-цепочки достаточно Save Project: исходный AVC остаётся на месте, а DGAVCIndex создаёт DGA. Это минимальный путь без лишнего копирования данных. Если источник уже является .264, повторно демультиплексировать его тем более бессмысленно — видеодорожка и так находится в элементарной форме.

Save Project and Demux Video полезен, когда входом служит транспортный поток, а кроме DGA нужен отдельный AVC elementary stream. Такой файл может пригодиться для другого muxer, анализа битстрима или передачи в программу, которая не читает TS. Операция не должна перекодировать изображение: задача состоит в извлечении видеопотока из транспорта.

Наличие отдельного AVC также упрощает диагностику. Если DGA, построенный напрямую по TS, вызывает проблемы, можно создать чистый elementary stream, проиндексировать уже его и сравнить результат. Совпадение ошибок указывает на сам H.264; исчезновение ошибок — на контейнерный разбор исходного TS.

Но создание дополнительного AVC увеличивает объём проекта и добавляет ещё один файл, который нельзя удалять, если DGA построен уже по нему. Поэтому для стабильного TS/M2TS лучше не усложнять цепочку без необходимости. Каждый лишний intermediate повышает риск перепутать версии или удалить тот источник, на который реально ссылается индекс.

При последующем remux отдельный AVC удобен ещё и тем, что можно соединить его с оригинальным аудио без повторного encode. В таком случае DGAVCDec используется только как индексатор/frameserver для версии, которую нужно фильтровать, а извлечённый битстрим может параллельно служить эталоном исходного видео.

Как переносить DGA-проект между каталогами и компьютерами

Индекс лучше считать частью конкретного рабочего окружения. Если проект нужно перенести на другой диск, самый надёжный способ — перенести исходный AVC/TS и заново создать DGA уже на новом месте. Индексация обычно намного дешевле, чем повторный encode, а новый проект гарантированно содержит актуальный путь.

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

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

На втором компьютере требуется тот же 32-bit AviSynth-стек и совместимая DGAVCDecode.dll. Один DGA не делает проект независимым от декодера. Если на новом ПК установлена только 64-bit AviSynth+, AVS с классическим DGAVCDecode не загрузится, даже если исходник и индекс лежат на правильных местах.

Для долгосрочного архива полезно сохранять рядом текстовый файл с путём к исходнику, разрядностью AviSynth и минимальным примером AVCSource(). Это быстрее восстанавливает контекст, чем попытка через годы угадать, какой из нескольких DG-инструментов создавал данный индекс.

Контрольные кадры как способ выявить несовместимость

При спорном источнике полезно выбрать несколько кадров с разной структурой: статичный I/IDR-участок, быстрое движение с большим количеством предсказания, монтажную склейку и место сразу после seek. Сравнение этих точек между DGAVCDec и альтернативным декодером даёт больше информации, чем случайный просмотр первых десяти секунд.

Если различия появляются только после произвольного перехода, но исчезают после последовательного декодирования, вероятна проблема random access. Если один и тот же макроблок повреждён всегда, нужно проверить сам битстрим. Если кадры визуально правильные, но номера смещаются, причина может быть в интерпретации pulldown или timestamps.

Для технического сравнения не следует использовать JPEG. Лучше сохранять без потерь либо сравнивать кадры внутри одной среды AviSynth. JPEG добавляет собственные блоки и цветовые преобразования, которые мешают отличить декодерный дефект от артефакта сохранения.

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

Такой подход делает DGAVCDec хорошим диагностическим инструментом даже тогда, когда финальный проект позже переводится на другой source-фильтр. DGA позволяет зафиксировать, как классический декодер трактует конкретный поток, и сравнить это с современной реализацией.

Итоговая рабочая схема

  1. Определить, что видеодорожка действительно AVC/H.264.
  2. Если это MP4/MKV, решить: демультиплексировать raw AVC или сразу выбрать FFMS2/L-SMASH Works.
  3. Открыть AVC/TS/M2TS в DGAVCIndex через File → Open.
  4. Проверить кадры, частоту и характер развёртки.
  5. При необходимости настроить Audio → Audio Demux.
  6. Осознанно выбрать Field Operation, не применяя Forced Film по умолчанию.
  7. Сохранить проект DGA через File → Save Project.
  8. Создать 32-разрядную совместимую AviSynth-цепочку с DGAVCDecode.dll.
  9. Открыть DGA через AVCSource и проверить несколько участков без фильтров.
  10. Добавить деинтерлейс/IVTC, crop, resize и другие операции.
  11. Отдельно обработать или сохранить аудио с правильным delay.
  12. Передать AVS в кодировщик и затем смультиплексировать результат.

DGAVCDec остаётся специализированным инструментом для тех случаев, где нужна классическая индексная работа с AVC/H.264 через AviSynth. Он особенно понятен на raw H.264 и совместимых TS/M2TS: один проход DGAVCIndex создаёт DGA, а AVCSource превращает этот индекс в источник кадров. При этом программа требует дисциплины — неизменного исходника, совпадающей разрядности, внимательного отношения к interlaced AVC и понимания того, что контейнеры MP4/MKV, современная временная модель и сложные варианты H.264 лучше обслуживаются более новыми source-фильтрами.