L-SMASH Works позволяет открывать видео и аудио через L-SMASH и FFmpeg в AviSynth, VapourSynth и AviUtl, выполнять точное индексированное позиционирование по кадрам, выбирать дорожки и декодеры, управлять преобразованием VFR в CFR, параметрами цвета и звука, а в AviUtl дополнительно мультиплексировать совместимые MP4/MOV, выгружать структуру контейнера и таймкоды.

Основная задача L-SMASH Works — не монтаж и не перекодирование сами по себе, а надёжная подача уже существующего медиапотока в программу, которая будет обрабатывать его дальше. В скриптовых средах он выступает source-фильтром: разбирает контейнер, выбирает нужный поток, декодирует кадры и выдаёт их в AviSynth или VapourSynth. В AviUtl тот же набор технологий оформлен как входной плагин с диалогом настроек, а рядом доступны узкие служебные модули для контейнеров ISO Base Media/QuickTime, дампа структуры и цветового обмена LW48/YC48.

Практически это означает, что выбор функции и режима важнее расширения файла. Для MP4 и MOV можно использовать путь с L-SMASH как демультиплексором, а для множества других контейнеров — LWLibav через libavformat. При кадровом монтаже и сложном seek особенно важен индекс .lwi: он хранит результаты разбора и избавляет от повторного полного сканирования при каждом открытии. При этом L-SMASH Works не обещает, что любой повреждённый, нестандартный или экзотический файл обязательно откроется: корректность зависит от контейнера, кодека, временных меток, структуры ключевых кадров и выбранного декодера.

Что именно делает L-SMASH Works

L-SMASH Works связывает несколько уровней медиатракта. На уровне контейнера используются два принципиально разных пути: L-SMASH для форматов семейства ISO Base Media/QuickTime и libavformat для более широкого набора контейнеров. На уровне декодирования задействован libavcodec и, в подходящих сборках, дополнительные специализированные декодеры. Снаружи это представлено функциями источника для AviSynth и VapourSynth либо File Reader в AviUtl. Поэтому корректнее воспринимать пакет как набор входных и вспомогательных модулей, а не как универсальный конвертер с одной кнопкой.

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

Второе важное свойство — индексирование. LWLibav-путь может создавать файл .lwi рядом с исходником либо в выбранном каталоге кэша. Индекс нужен не для изменения медиафайла, а для быстрого и точного доступа к его временной структуре: соответствию кадров временным меткам, положению точек произвольного доступа, параметрам потоков. После построения корректного индекса повторное открытие обычно не требует заново разбирать весь файл. Если исходник изменился, а старый индекс остался, его необходимо удалить и построить заново.

Третья особенность — раздельная работа с временной моделью. L-SMASH Works умеет отдавать переменную частоту кадров как есть либо сформировать CFR на заданной дроби fps, добавляя или отбрасывая кадры. Это не исправление любого рассинхрона одной галочкой: выбор числителя и знаменателя должен соответствовать задаче, а для монтажа с сохранением исходной временной разметки зачастую правильнее не включать принудительное преобразование без необходимости.

Компоненты и где они используются

Компонент	Среда	Назначение
LSMASHSource.dll	AviSynth	Функции LSMASHVideoSource, LSMASHAudioSource, LWLibavVideoSource и LWLibavAudioSource для получения видео и звука в скрипте.
LSMASHSource.dll	VapourSynth	Функции пространства lsmas, прежде всего LibavSMASHSource и LWLibavSource, выдающие VideoNode.
lwinput.aui / соответствующий модуль AviUtl	AviUtl	L-SMASH Works File Reader: чтение медиа, AVS/VSScript, индексирование и настройки постобработки.
lwmuxer.auf	AviUtl	Мультиплексирование контейнеров, производных от ISO Base Media и QuickTime, с поддержкой глав и оптимизации progressive download.
lwdumper.auf	AviUtl	Выгрузка текстового дерева box-структуры и timecode v2.
lwcolor.auc	AviUtl	Прямая передача между LW48 и внутренним YC48 без обычной цветовой математики преобразования.

Не все компоненты нужны одновременно. Для скриптового фильтрационного конвейера достаточно source-плагина соответствующей разрядности и среды. Для AviUtl типичный минимум — File Reader; остальные файлы добавляют отдельные операции и не превращают входной плагин в видеоредактор. Важно также не путать L-SMASH Works с библиотекой L-SMASH: последняя отвечает за работу с контейнерами семейства MP4/MOV, тогда как Works оборачивает её и FFmpeg-компоненты в плагины для конкретных хостов.

Два пути чтения: L-SMASH и LW-Libav

В названиях функций отражено различие демультиплексоров. LSMASHVideoSource и родственные функции используют L-SMASH для разбора контейнера и libavcodec для декодирования. Этот путь естественен для MP4, M4V, MOV, 3GP и других форматов, основанных на ISO Base Media или QuickTime. LWLibavVideoSource и LWLibavSource используют libavformat как демультиплексор и libavcodec как декодер, поэтому они применимы к гораздо более широкому набору контейнеров и чаще выбираются как универсальный вариант.

Практическое различие проявляется не только в списке расширений. LW-Libav строит собственный индекс .lwi и тем самым получает подробную карту кадров для последующего точного seek. L-SMASH-путь опирается на структуру контейнера и точки произвольного доступа, что для корректных MP4/MOV может быть удобно, но при длительной обработке разработчики прямо рекомендуют учитывать, что LSMASHVideoSource/LibavSMASHSource способны быть менее производительными, чем LWLibavVideoSource/LWLibavSource, если задача выходит за рамки быстрого предпросмотра.

Нет правила один путь всегда лучше. Если файл корректно размечен как MP4/MOV и нужен быстрый доступ без отдельного .lwi, L-SMASH может быть уместен. Если требуется устойчивый покадровый доступ к длинному исходнику, работа с контейнером вне семейства MP4/MOV, явный выбор stream_index или повторное использование индекса, LW-Libav обычно удобнее. При ошибках полезно менять именно демультиплексор, сохраняя остальные параметры максимально близкими: так легче понять, какой уровень вызывает проблему.

AviSynth: основные функции источника

LSMASHVideoSource

LSMASHVideoSource открывает видеодорожку через L-SMASH и декодирует её libavcodec. Обязательный параметр source задаёт путь. track=0 означает автоматический выбор первой обнаруженной видеодорожки; положительное значение позволяет обратиться к конкретной дорожке. threads=0 передаёт выбор количества потоков декодеру. seek_mode и seek_threshold определяют поведение при случайном доступе и ошибках около точек произвольного доступа. fpsnum и fpsden задают целевой CFR, если требуется принудительное преобразование временной сетки.

Параметр format нужен не для смены контейнера, а для принудительного выходного пиксельного формата. В зависимости от сборки и среды доступны семейства YUV420/YUV422/YUV444 с разной битностью, а также отдельные упакованные или RGB-варианты. Принудительный формат может отключать direct rendering, потому что перед выдачей кадра требуется дополнительное преобразование. Если следующий фильтр способен принять нативный формат источника, оставлять format пустым обычно рациональнее.

v = LSMASHVideoSource("D:\\video\\source.mp4", track=0)
return v

LSMASHAudioSource

LSMASHAudioSource получает аудиодорожку того же семейства контейнеров. track=0 просит выбрать первый найденный аудиопоток. skip_priming управляет пропуском priming samples, которые могут быть описаны метаданными вроде iTunSMPB или монтажными edit-структурами. layout задаёт выходную раскладку каналов, rate — частоту дискретизации, decoder — список предпочтительных декодеров. Для lossy-аудио при случайном доступе применяется pre-roll, потому что корректный результат декодирования может зависеть от предшествующих пакетов.

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

LWLibavVideoSource

LWLibavVideoSource — основной индексируемый видеовход AviSynth. stream_index=-1 означает автоматический выбор видеопотока с наибольшим разрешением. cache включает создание индекса; в расширенных сборках доступны cachefile и cachedir для управления расположением .lwi. seek_mode, seek_threshold, fpsnum/fpsden, repeat, dominance, format и decoder покрывают временную структуру, интерлейс, формат выдачи и выбор декодера. Параметры prefer_hw и ff_options, если они доступны в используемой сборке, добавляют управление аппаратным ускорением и параметрами FFmpeg.

v = LWLibavVideoSource("D:\\capture\\camera.mkv", cache=true)
return v

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

LWLibavAudioSource

LWLibavAudioSource работает с аудиопотоками через libavformat/libavcodec и разделяет параметры потока и постобработки. stream_index=-1 выбирает первый подходящий аудиопоток. cache использует ту же систему индекса. av_sync пытается скорректировать начальное выравнивание аудио относительно активного видеопотока, отмеченного в индексе. layout и rate задают выходную конфигурацию каналов и частоту дискретизации. В новых реализациях встречаются дополнительные параметры для заполнения аудиопробелов тишиной, коэффициента DRC и FFmpeg options; применять их стоит только когда понятна причина дефекта исходника.

a = LWLibavAudioSource("D:\\capture\\camera.mkv", cache=true)
v = LWLibavVideoSource("D:\\capture\\camera.mkv", cache=true)
return AudioDub(v, a)

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

VapourSynth: LibavSMASHSource и LWLibavSource

В VapourSynth функции находятся в пространстве lsmas. LibavSMASHSource использует L-SMASH как демультиплексор и libavcodec как декодер. LWLibavSource использует libavformat и индекс .lwi. В отличие от AviSynth, интерфейс задаётся вызовом Python-скрипта через core, но смысл основных параметров тот же: source, track или stream_index, threads, seek_mode, seek_threshold, fpsnum/fpsden, variable, format, decoder, prefer_hw, ff_loglevel и ff_options.

import vapoursynth as vs
core = vs.core
clip = core.lsmas.LWLibavSource(source=r"D:\\video\\source.mkv")
clip.set_output()

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

LWLibavSource умеет хранить индекс в явном cachefile либо в cachedir. Последний вариант удобен для рабочих станций, где медиапапки должны оставаться чистыми: имя индекса формируется так, чтобы кодировать полный путь и уменьшать вероятность коллизий. Параметр rap_verification определяет, нужно ли при индексации дополнительно проверять найденные random access points декодированием. Такая проверка повышает надёжность на спорных потоках, но замедляет построение индекса; изменение этого режима требует удалить старый .lwi, иначе в работу попадут данные, созданные с другой политикой.

Индекс .lwi: зачем он нужен и когда его удалять

Индекс LWLibav — один из ключевых элементов L-SMASH Works. Контейнер может хранить пакеты в порядке, отличном от порядка отображения кадров, а кодек использует ссылки на соседние кадры и ключевые точки. Для мгновенного перехода к кадру недостаточно знать его порядковый номер: надо определить подходящую точку начала декодирования, восстановить зависимые кадры, учесть PTS/DTS и повторные поля. Индекс сохраняет результат предварительного анализа, поэтому seek после первого открытия становится значительно предсказуемее.

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

Отключать cache имеет смысл в редких задачах: одноразовая линейная обработка, файлы на носителе только для чтения, среда с централизованным кэшем или отладка. Для обычного монтажа отказ от индекса часто только переносит стоимость анализа на каждое открытие. Если нежелательно засорять каталоги медиаданных, лучше использовать cachefile/cachedir там, где это поддержано, чем полностью выключать индексирование.

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

Seek, RAP и параметры случайного доступа

RAP — random access point, то есть место, от которого декодер может начать восстановление последовательности кадров. В межкадровых кодеках переход к произвольному кадру обычно означает: найти ближайшую пригодную точку до целевого кадра, начать декодирование от неё и последовательно дойти до запрошенной позиции. seek_threshold задаёт границу, при которой выгоднее продолжить декодировать вперёд от уже открытого состояния, а не выполнять новый seek к RAP. Слишком маленький порог увеличивает число перестановок, слишком большой заставляет декодировать длинные участки при скачках по таймлайну.

seek_mode определяет стратегию при фатальных ошибках декодирования во время перехода. Нормальный режим пытается восстановиться через повторный поиск точки доступа; более терпимые режимы могут вернуть последний корректный кадр вместо остановки. Это полезно для предпросмотра повреждённого файла, но опасно для финального кадр-точного процесса: незаметно повторённый кадр маскирует ошибку и меняет содержимое. Если точность важнее непрерывности, проблему лучше локализовать, а не превращать aggressive/unsafe в постоянную настройку.

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

VFR и CFR: как не получить рассинхрон

VFR хранит кадры с разными временными интервалами. Для такой записи корректная длительность определяется таймстампами, а не простым отношением номера кадра к постоянному fps. L-SMASH Works может преобразовать VFR в CFR с помощью fpsnum/fpsden или настройки VFR->CFR в AviUtl, выбирая равномерную сетку и добавляя либо отбрасывая кадры. Это преобразование меняет набор отображаемых кадров; оно не является нейтральной операцией.

Числитель и знаменатель задаются как дробь. Типичные значения 24000/1001, 30000/1001 и 60000/1001 соответствуют примерно 23,976, 29,97 и 59,94 кадра/с. Значения 24/1, 30/1 и 60/1 — ровно 24, 30 и 60. Подмена 60000/1001 на 60/1 создаёт небольшую, но постоянную разницу временной сетки. На коротком ролике она может быть незаметна, а на длинном материале приводит к накоплению расхождения относительно внешнего звука или таймкодов.

Если редактор умеет корректно работать с VFR и задача требует сохранить исходные времена, принудительный CFR не нужен. Если downstream-инструмент ожидает постоянный fps, лучше выбрать целевую частоту осознанно. В AviUtl старая практика всегда включить VFR->CFR 60000/1000 неприменима ко всем файлам: материал 25 fps, 29,97 fps или истинный VFR требует другой логики. При зелёных кадрах, изменившейся длительности или новом рассинхроне после включения VFR->CFR настройку следует вернуть и проверить реальные временные метки источника.

Интерлейс, repeat flags и field dominance

Параметр repeat относится к флагам повторного отображения полей/кадров, которые встречаются в телесинном и некоторых вещательных потоках. LWLibav может реконструировать последовательность с учётом этих флагов и затем трактовать кадры как интерлейсные, когда это применимо. Если одновременно включено принудительное VFR->CFR, логика repeat может быть проигнорирована, потому что временная сетка уже формируется другим механизмом.

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

Отдельная проблема — fake interlaced, когда поток помечен как интерлейсный, но по содержанию фактически прогрессивен. Слепое применение repeat и деинтерлейса может ухудшить материал. В VapourSynth документация отдельно предупреждает о сочетаниях repeat/cache для таких случаев. Правильная стратегия — сначала определить характер источника, затем выбирать режим, а не исходить только из одного контейнерного флага.

Выбор декодера и аппаратное ускорение

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

prefer_hw управляет классом аппаратного декодирования в сборках, где эта функция включена. Доступны варианты, соответствующие NVDEC/CUVID, QSV, DXVA2, D3D11VA, D3D12VA и Vulkan, а также режимы последовательной попытки нескольких backend. Это ускоряет только этап декодирования. Если затем кадры приходится копировать в системную память и выполнять тяжёлые CPU-фильтры, общий выигрыш может быть небольшим или даже отрицательным из-за преобразований и синхронизации.

Аппаратный декодер может выдавать иной набор допустимых пиксельных форматов, иначе реагировать на повреждённые потоки или не поддерживать определённый профиль. Поэтому при странных цветах, ошибке инициализации, пропусках кадров или различии результата первый диагностический шаг — prefer_hw=0 и пустой decoder. Если software-декодирование стабильно, затем аппаратный путь можно включать по одному backend и проверять конкретную связку кодек/GPU/драйвер.

ff_loglevel полезен для диагностики. Нулевой уровень подавляет сообщения, а более высокие уровни постепенно открывают warnings, info, verbose, debug и trace. В постоянном рабочем скрипте избыточный лог не нужен, но при неизвестной ошибке чтения временное включение AV_LOG_WARNING или AV_LOG_DEBUG помогает увидеть, на каком этапе возникает проблема: demux, parser, decoder, timestamp correction или аппаратный backend. ff_options передаёт дополнительные ключи FFmpeg в формате key=value; это инструмент для осознанной настройки, а не список универсальных ускорителей.

Пиксельные форматы и direct rendering

L-SMASH Works способен отдавать разные YUV и RGB-представления, но правильный выбор определяется дальнейшей цепочкой. Если фильтры работают в YUV420P10, принудительный переход в RGB32 на входе создаёт лишнюю конверсию и может изменить матрицу/диапазон. Если требуется конкретный формат для старого AviSynth-фильтра, format позволяет выполнить преобразование один раз непосредственно на источнике. В остальных случаях полезно оставить нативный формат и сделать цветовое преобразование отдельным, явно настроенным фильтром.

Direct rendering означает попытку дать декодеру писать данные кадра непосредственно в буфер, который затем получит хост, сокращая копирование. Однако принудительный format, stacked-представление и некоторые несовместимые условия отключают этот путь. dr=true не гарантирует ускорение на любом материале: если downstream-фильтры всё равно копируют кадры или формат надо конвертировать, выигрыш исчезает. Важно сравнивать не только скорость открытия, но и стабильность всей цепочки.

Высокая битность требует согласованности. 10-, 12-, 14- и 16-битные форматы полезны для сохранения точности, но хост и каждый последующий фильтр должны их поддерживать. Старый фильтр, ожидающий только 8 бит, может отказать или принудительно преобразовать данные. Если конечная цель — 8-битный кодек, это не означает, что источник надо сразу опустить до 8 бит: промежуточная обработка в более высокой точности часто уменьшает накопление округлений.

Аудио: раскладка каналов, частота и задержка

layout задаёт, какие каналы и в каком порядке должен выдавать аудиоисточник. Можно использовать имена отдельных каналов FL, FR, FC, LFE, BL, BR, SL, SR и другие либо стандартные раскладки mono, stereo, 5.1, 7.1. Это не инструмент для творческого панорамирования: источник и ресемплер приводят поток к указанной схеме. Если задать несовместимую раскладку, часть каналов будет смешана, отброшена или заполнена согласно возможностям используемого resampler.

rate=0 сохраняет автоматический выбор, ориентированный на максимальную частоту в потоке, а явное значение, например 48000, заставляет ресемплер выдать указанную частоту. Это удобно, когда цепочка требует единого sample rate. Однако не следует менять 44100 на 48000 только потому, что видео обычно 48 кГц: ресемплинг имеет смысл при реальной совместимости с монтажом, микшированием или кодером. Если звук и видео уже синхронны, изменение rate само по себе не исправляет таймстампы.

Audio delay в AviUtl задаётся в PCM-сэмплах. Положительное значение добавляет тишину в начало и задерживает звук; отрицательное отбрасывает начальные сэмплы и сдвигает звук раньше. Пересчёт в секунды зависит от sample rate: при 48000 Гц сдвиг на 4800 сэмплов равен 0,1 секунды. Это точная ручная коррекция известного постоянного смещения, но не средство против постепенно нарастающего рассинхрона, который обычно связан с частотой кадров, неправильной длительностью или ошибочными timestamps.

A/V sync correction пытается выровнять начало звука по первой видеопозиции, активной в индексе. Полезность настройки зависит от того, как контейнер описывает старт потоков. Если аудио намеренно начинается раньше видео либо монтажные edit-списки задают сложное начало, автоматическая коррекция может не соответствовать творческой задаче. При спорном результате лучше сравнить начало дорожек с выключенной и включённой коррекцией и зафиксировать вариант, соответствующий таймстампам.

L-SMASH Works File Reader в AviUtl

В AviUtl большинство пользователей взаимодействует с L-SMASH Works через один диалог File Reader. В нём одновременно собраны переключатели демультиплексоров, параметры декодирования, VFR->CFR, аудиопостобработка, управление индексом и служебный dummy reader. Это удобнее скриптовых вызовов, но логика та же: каждая галочка соответствует конкретному слою обработки, поэтому копирование чужого набора настроек без понимания может ухудшить именно ваш материал.

Диалог открывается через настройки входных плагинов. Сам факт наличия пункта L-SMASH Works File Reader подтверждает, что модуль распознан хостом, но не гарантирует, что конкретный файл действительно будет открыт им: AviUtl использует приоритеты входных плагинов. Если другой reader стоит выше и заявляет то же расширение, файл может обрабатываться им. Поэтому при диагностике нужно проверять и приоритет, и сведения о фактически использованном input plugin.

Верхняя строка переключает Libav+L-SMASH, AviSynth Script, VSScript и LW-Libav. File Reader пробует разрешённые пути в определённом порядке. Если Libav+L-SMASH включён, подходящий MP4/MOV сначала будет попытка открыть через L-SMASH. При его отключении файл может перейти к LW-Libav. Это полезный диагностический переключатель: проблемы одного demuxer не означают, что кодек вообще не поддерживается.

threads, Forward threshold и Seek mode

threads=0 оставляет выбор числа потоков декодеру; это нормальная исходная настройка. Ручное уменьшение бывает полезно для диагностики, старых систем или одновременной обработки большого количества файлов, где каждый источник иначе создаёт слишком много потоков. Увеличивать число выше автоматического значения бессмысленно, если сам декодер уже ограничен структурой потока или памятью.

Forward threshold соответствует логике последовательного продвижения при seek. Значение 10 означает, что небольшие переходы вокруг текущей позиции могут быть выгоднее последовательного декодирования, чем нового поиска RAP. При монтаже с частыми крупными прыжками слишком высокий порог ухудшит отзывчивость; при линейном просмотре эффект обратный. Поэтому менять его стоит только после того, как исключены индексация, медленный накопитель и аппаратный декодер как причины задержек.

Seek mode задаёт, как reader ведёт себя после фатальной ошибки. Более терпимый режим помогает продолжать просмотр битого файла, но может вернуть последний корректный кадр. Для визуального просмотра это лучше чёрного экрана; для точного монтажа это риск скрытого повторения. Если ошибка повторяется на одном месте, полезнее извлечь проблемный участок или ремультиплексировать исходник, чем закреплять tolerant-режим для всех проектов.

Video scaler и цветовая часть

Video scaler используется при chroma upsampling, например когда исходный YUV 4:2:0 надо подать в представление с более плотной цветностью. По умолчанию часто выбран Fast bilinear. Это не масштабирование размера кадра, а алгоритм интерполяции цветоразностных компонент. Для интерлейсного YUV 4:2:0 применяется отдельная схема, учитывающая расположение цветности MPEG-2. Поэтому изменение Video scaler не должно рассматриваться как способ сделать картинку резче вообще.

Create Index file, cache directory и обслуживание индекса

Create Index file включает .lwi для LW-Libav. В расширенных диалогах могут присутствовать Handle cache, Use cache dir, Delete old cache и поле каталога кэша. Такой режим удобен, если в папках с медиа не должны появляться служебные файлы. При централизованном кэше полезно периодически удалять индексы для исходников, которых уже нет, но автоматическое удаление надо выбирать с запасом: старый проект может обращаться к редко используемому файлу и после очистки потребует повторной индексации.

Если настройки reader изменены, но старый .lwi продолжает использовать результаты прежнего анализа, не все изменения проявятся. Особенно это относится к параметрам, влияющим на индексацию и RAP verification. Поэтому при диагностике корректная последовательность такая: закрыть хост, изменить параметры, удалить относящийся к исходнику индекс, открыть файл заново и дождаться нового сканирования.

Libav video index и Libav audio index

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

Dummy resolution, Dummy framerate и Dummy colorspace

AviUtl исторически ожидает наличие видео даже для аудиофайла. Dummy reader создаёт служебный видеопоток, если видео отключено или отсутствует. Dummy resolution определяет его размер, Dummy framerate — временную сетку, Dummy colorspace — формат. Чем выше dummy framerate, тем более мелким шагом можно адресовать положение аудио по кадрам, но это увеличивает число условных кадров. Для чистого аудиомонтажа разумно выбирать fps, обеспечивающий достаточную временную точность без абсурдно большого проекта.

AVS bit-depth, AviSynth Script и VSScript

Флажки AviSynth Script и VSScript разрешают File Reader открывать .avs и .vpy через соответствующие script API. В этом сценарии L-SMASH Works не заменяет сам AviSynth/VapourSynth: он лишь даёт AviUtl возможность принимать результат скрипта. AVS bit-depth сообщает, как интерпретировать компоненты, возвращаемые AviSynth. Неправильное значение приводит к некорректной трактовке данных, поэтому его следует согласовать с реальным форматом вывода скрипта.

Приоритет входных плагинов в AviUtl

AviUtl выбирает reader не по названию программы, а по списку приоритетов и поддерживаемым расширениям. Если несколько модулей заявляют MP4, первый подходящий может перехватить файл. Поэтому настройка приоритета — часть функционального поведения L-SMASH Works. Нельзя дать единую таблицу всегда ставьте первым: выбор зависит от того, какие ещё input plugins установлены и какие форматы они обслуживают лучше. В типичной схеме L-SMASH Works ставят выше менее предсказуемых универсальных fallback-reader, но специализированный reader для конкретного формата может иметь смысл расположить выше.

Проверка Другие/Сведения о входных плагинах показывает, что L-SMASH Works загружен, но при проблеме с конкретным файлом полезнее дополнительно посмотреть информацию о файле и фактически использованном reader. Если настройки L-SMASH Works не оказывают никакого эффекта, очень часто причина в том, что файл открыл другой плагин. В таком случае изменение VFR->CFR, decoder или cache в L-SMASH Works ничего не меняет, пока не исправлен приоритет.

В новых вариантах AviUtl интерфейс приоритетов может выглядеть иначе, но принцип сохраняется: L-SMASH Works File Reader отображается в списке вместе с другими reader, а набор расширений влияет на то, какие файлы он может заявить. Если добавлять расширение вручную, это только разрешает попытку открытия; поддержка самого контейнера и кодека всё равно определяется demuxer/decoder.

LW48 и цветовой обмен с AviUtl

LW48 — определённый L-SMASH Works упакованный 48-битный формат YUV, где на каждый компонент Y, Cb и Cr приходится по 16 бит. В описании формата уровни опираются на BT.601: чёрному и белому соответствуют определённые целочисленные диапазоны, а нейтральная цветоразностная компонента находится около середины шкалы. Для AviUtl это особый путь, позволяющий передать данные в внутреннее YC48-представление простым копированием, если активирован lwcolor.auc.

Преимущество — меньше лишней цветовой математики между входом и внутренним буфером. Но это не означает автоматического улучшения качества всех проектов. Фильтры AviUtl могут предполагать стандартный диапазон YC48; значения вне ожидаемого диапазона способны вести себя неожиданно. Если включён LW48 output, необходимо включить и соответствующую цветовую конверсию LW ColorSpace, а на выходе использовать путь, который понимает такой режим. Иначе цепочка окажется несогласованной.

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

L-SMASH Works Muxer в AviUtl

lwmuxer.auf выполняет мультиплексирование, но только для контейнеров, производных от ISO Base Media и QuickTime. Это важное ограничение: модуль не является универсальным muxer для MKV, MPEG-TS или WebM. Его задача — собрать совместимые дорожки в MP4/M4A/M4V/MOV-подобный контейнер без превращения в полноценный кодировщик.

Поле Chapter принимает путь к простому текстовому файлу с главами. Для ISO Base Media записывается список глав, а для iTunes-подобных MP4 или QuickTime может создаваться reference chapter track. Формат и кодирование файла глав должны соответствовать тому, что ожидает плагин; если главы не нужны, поле следует оставить пустым.

Optimize for Progressive Download переносит служебные данные, необходимые для доступа к образцам, ближе к началу готового файла. Для MP4 это аналог идеи fast start: проигрыватель может получить метаданные раньше, не дожидаясь загрузки конца файла. Операция выполняется на этапе завершения mux и может потребовать дополнительной переработки структуры файла. Она полезна для последовательной доставки, но не влияет на качество кодека.

L-SMASH Works Dumper и Timecode v2

lwdumper.auf предназначен для анализа ISO Base Media/QuickTime-контейнеров. Режим Dump File создаёт текстовое представление box-структуры. Это полезно для диагностики, когда нужно увидеть moov, trak, mdia, stbl и другие атомы/boxes, проверить наличие edit list, sample table или расположение метаданных. Такой дамп не декодирует каждый кадр и не заменяет медиаплеер; он показывает структурный слой контейнера.

Режим Timecode v2 выгружает временную сетку в формате, совместимом с mkvmerge timecode v2. Это особенно полезно для VFR: вместо усреднённого fps можно получить последовательность времён кадров и передать её другому инструменту. Если задача — сохранить переменную временную сетку при ремультиплексировании, timecode-файл информативнее принудительного CFR.

Dumper поддерживает только контейнеры семейства ISO Base Media/QuickTime. Попытка использовать его как общий анализатор Matroska или TS выходит за назначение. Для таких контейнеров следует применять специализированные анализаторы, а L-SMASH Works использовать на уровне чтения через LW-Libav.

Форматы: что означает поддерживается

У L-SMASH Works нет короткого фиксированного списка все поддерживаемые форматы, потому что LW-Libav зависит от возможностей встроенного/подключённого FFmpeg-стека. Расширение файла — только подсказка. MP4 может содержать H.264, HEVC, AV1, AAC, ALAC и множество других комбинаций; MKV — ещё более широкий набор; MOV способен содержать как распространённые, так и профессиональные кодеки. Файл считается реально поддерживаемым только если demuxer распознаёт контейнер, decoder понимает поток, а выходной формат можно представить хосту.

Поэтому ситуации MP4 открывается, другой MP4 нет нормальны с точки зрения архитектуры. Причиной может быть другой codec profile, повреждённая sample table, нестандартные timestamps, зашифрованный поток, edit list, unusual channel layout или аппаратный декодер, который не поддерживает конкретный вариант. Диагностика должна идти от контейнера к потоку: определить codec/stream, выключить принудительные decoder/prefer_hw, сравнить L-SMASH и LW-Libav, пересоздать индекс, затем рассматривать повреждение исходника.

DRM и шифрованные потоки не становятся доступными только из-за поддержки контейнера. L-SMASH Works не является средством снятия защиты. Аналогично наличие декодера не гарантирует корректное чтение файла, если его структура нарушена настолько, что demuxer не может восстановить пакеты и таймстампы.

Практический сценарий: MP4 или MOV для кадр-точного монтажа

1. Сначала откройте файл без принудительного decoder и без аппаратного prefer_hw, чтобы получить базовый программный результат.
2. Если нужен многократный random access, используйте LWLibavVideoSource/LWLibavSource с индексом .lwi либо соответствующий LW-Libav режим File Reader.
3. Не включайте VFR->CFR до проверки, действительно ли downstream требует постоянный fps. Для VFR сначала оцените исходные timestamps.
4. Если в контейнере несколько потоков, укажите track/stream_index явно и отдельно выберите аудио.
5. После изменения параметров индексации удалите старый .lwi и постройте индекс заново.

Такой порядок исключает большую часть ложных причин. Если сначала включить hardware, forced format, CFR и нестандартный decoder, а потом получить ошибку, приходится одновременно проверять четыре независимых слоя. Базовый software path с нативной временной сеткой — контрольная точка, от которой изменения добавляются по одному.

Практический сценарий: MKV, WebM и другие контейнеры

Для Matroska/WebM и большинства контейнеров вне семейства ISO Base Media основной путь — LW-Libav. В AviSynth это LWLibavVideoSource/LWLibavAudioSource, в VapourSynth — lsmas.LWLibavSource, в AviUtl — включённый LW-Libav reader. stream_index особенно полезен для MKV с несколькими языковыми дорожками и commentary. Если контейнер содержит attachments или обложки, автоматический выбор видеопотока по разрешению обычно отсекает мелкие изображения, но при сложной структуре лучше проверить индекс потока явно.

WebM с альфа-каналом зависит от декодера и формата выдачи. Рекомендации в сообществе часто используют preferred decoder libvpx/libvpx-vp9 для определённых прозрачных WebM, но это не универсальная настройка для всех файлов. Если прозрачность важна, надо проверить, что декодер действительно отдаёт alpha и что AviUtl/VapourSynth цепочка её сохраняет. Принудительное преобразование в формат без alpha уничтожит канал независимо от того, что контейнер его содержит.

Практический сценарий: VFR с телефона или захвата экрана

Записи смартфонов и некоторые screen recorder создают VFR, потому что интервалы кадров адаптируются к нагрузке или сцене. Если монтажная среда корректно понимает VFR, сохранение исходных timestamps максимально точно отражает захваченный материал. Если среда ожидает CFR, сначала надо определить разумную целевую сетку: 30, 30000/1001, 60, 60000/1001 или другую. Затем проверить участки с максимальной вариативностью интервалов и убедиться, что добавленные/удалённые кадры не создают заметных рывков.

Если звук постепенно уходит относительно картинки, не стоит начинать с Audio delay: постоянный сдвиг не исправит нарастающую ошибку. Нужно проверить, не был ли VFR ошибочно прочитан как CFR, не перепутаны ли 60 и 60000/1001, не изменил ли хост длительность при импорте. Только после восстановления правильной временной базы имеет смысл корректировать остаточный постоянный offset.

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

Когда в исходнике нет видео, File Reader создаёт dummy video, потому что хост ожидает видеопоток. Для подкаста или длинной дорожки разумно выбрать небольшое Dummy resolution и fps, который даёт нужную точность позиционирования. Например, 100 fps даёт сетку 10 мс, но создаёт намного больше условных кадров, чем 25 или 30 fps. Если точность редактирования определяется аудиосэмплами другим инструментом, завышать dummy fps в AviUtl нет смысла.

Sampling rate лучше согласовать с проектом заранее. Если весь монтаж и конечный кодер работают в 48 кГц, можно ресемплировать вход на 48000, но исходник 44,1 кГц при этом действительно преобразуется. Channel layout также следует задавать только при необходимости: неправильное принудительное stereo или 5.1 способно изменить содержимое каналов ещё до микширования.

Практический сценарий: несколько дорожек

Файлы с несколькими video/audio streams требуют явного выбора. В AviSynth L-SMASH путь использует track, а LWLibav — stream_index. Эти числа не обязательно совпадают: track относится к логике контейнера L-SMASH, stream_index — к индексам потоков libavformat. Поэтому значение, найденное одним анализатором как stream 2, нельзя бездумно перенести в track=2. Для AviUtl поля Libav video index и Libav audio index относятся именно к libavformat stream index.

Если нужная аудиодорожка имеет другой sample rate или channel layout, L-SMASH Works может сразу привести её к общему формату. Но для архивной обработки лучше сначала получить оригинальные каналы и уже затем выполнять явное преобразование: так проще контролировать, не потерялась ли LFE/center дорожка и не произошёл ли нежелательный downmix.

Ошибки открытия: системный порядок диагностики

1. Проверить, какой reader реально открыл файл.
2. Удалить старый .lwi, если исходник менялся.
3. Отключить forced decoder и prefer_hw.
4. Оставить нативный fps и format.
5. Сравнить LW-Libav и Libav+L-SMASH для MP4/MOV.
6. Явно выбрать нужный stream/track.
7. Включить FFmpeg loglevel для получения текста ошибки.

Если файл вообще не распознаётся, проблема обычно на уровне demux. Если контейнер открывается, но конкретный поток нет — на уровне decoder или параметров профиля. Если первые кадры корректны, а seek ломается позже — проверяют индекс, RAP и повреждения потока. Если видео корректно, а звук уходит — timestamps, sample rate, VFR/CFR и start offset. Такое разделение сокращает диагностику и не требует менять все настройки одновременно.

Чёрный или зелёный кадр

Зелёный кадр часто указывает на ошибку декодирования или несовместимый формат/аппаратный backend, но может возникать и при неправильной временной конверсии. Сначала выключают hardware и forced decoder, затем forced format, затем VFR->CFR. Если software path даёт правильную картинку, компоненты включают обратно по одному. Если ошибка остаётся, полезно сравнить другой demuxer и проверить тот же поток внешним декодером.

Длина файла неверна

Неверная длительность обычно связана с timestamps, repeat flags, VFR/CFR или старым индексом. После ремультиплексирования .lwi нужно удалить. Если включён repeat, временная модель может отличаться от простого количества coded frames. Если VFR принудительно превращён в CFR, длина определяется новой сеткой. Для диагностики отключают repeat и CFR, строят новый индекс и сравнивают длительность, вычисленную по реальным timestamps.

Seek зависает или долго прыгает

Первое открытие может строить индекс; это нормальный разовый процесс. Если каждый переход медленный уже после индексации, проверьте, используется ли именно этот .lwi, не находится ли исходник на медленной сети, не слишком ли велик seek_threshold и не выбрана ли функция LSMASHVideoSource/LibavSMASHSource там, где индексируемый LWLibav path был бы эффективнее. Для длинного GOP даже точный seek требует декодировать кадры от предыдущего RAP, поэтому мгновенный переход не гарантируется самим наличием индекса.

Аудио трещит или обрывается после seek

Lossy-аудио требует pre-roll; плагин учитывает это, но повреждённые пакеты, неправильный start time или принудительный decoder могут дать артефакт. Сначала проверяют software decoder и исходную частоту, затем отключают ручной Audio delay и необычный layout. Если проблема возникает только после случайного доступа, полезно сравнить линейный экспорт участка и повторный seek. Для файла с битой структурой ремультиплексирование иногда восстанавливает таблицы пакетов без перекодирования.

Файл с нелатинским именем не открывается

Для AviSynth-пути проблема может быть связана не с контейнером, а с кодировкой пути. Документация рекомендует сохранять .avs в UTF-8 либо использовать системную UTF-8 code page, если это допустимо в конкретной Windows-конфигурации. Перед изменением глобальной локали проще проверить тот же файл с коротким ASCII-путём. Если он открывается, причина почти наверняка в передаче имени, а не в декодере.

Производительность: что действительно влияет

Скорость чтения складывается из четырёх этапов: demux/index, decode, преобразование формата и работа downstream-фильтров. Ускорение только decode через GPU не поможет, если bottleneck — тяжёлая индексация по медленной сети или цветовое преобразование каждого кадра. Аналогично увеличение threads не ускорит аппаратный backend, который управляет параллелизмом сам. Для оценки нужно разделять время первого открытия, скорость повторного открытия и скорость последовательной обработки.

На длинных исходниках LWLibav с сохранённым индексом обычно выгоднее повторяющихся полных сканирований. В VapourSynth cachedir позволяет вынести индексы на быстрый SSD. В AviUtl централизованный cache directory решает ту же организационную задачу. Если медиаданные лежат на NAS, локальный кэш уменьшает число мелких запросов к сети, хотя само декодирование всё равно читает исходные пакеты по сети.

Forced format стоит применять только для совместимости. Каждая конверсия 4:2:0→4:4:4, 8→16 bit или YUV→RGB требует вычислений и памяти. Если цепочка фильтров сразу возвращает данные в другой формат, можно получить двойное преобразование. Оптимальная схема — открыть максимально близко к нативному формату, выполнить фильтрацию в осознанном рабочем пространстве и только перед кодером перейти в требуемый выходной формат.

При одновременной обработке нескольких источников автоматический threads у каждого decoder может перегрузить CPU. В таком случае ограничение threads на уровне источников иногда повышает суммарную пропускную способность, потому что уменьшается конкуренция и переключение контекста. Это особенно заметно в VapourSynth, где сама графовая обработка уже распараллеливает кадры. Универсального числа нет: оно зависит от кодека, количества одновременных клипов и фильтров.

L-SMASH Works и AviUtl2

В AviUtl2 File Reader отображается как отдельный входной плагин в списке, а конфигурация может включать дополнительные элементы управления кэшем и широким диалогом. Основные понятия остаются теми же: Libav+L-SMASH и LW-Libav — два demux-path, Create Index file создаёт .lwi, VFR->CFR меняет временную сетку, Preferred decoders задаёт приоритет codec implementations. Если интерфейс хоста изменил путь к настройкам, это не меняет смысл параметров.

Особенно важно не переносить механически старые советы по приоритетам. Состав встроенных readers у разных поколений AviUtl отличается. Нужно смотреть фактический список и то, какой модуль перехватывает расширение. L-SMASH Works полезен именно как reader; если другой input plugin лучше обслуживает узкий формат, его можно поставить выше, не удаляя L-SMASH Works.

Сравнение L-SMASH Works с аналогами

Программа	Лучше подходит для	Главное ограничение
L-SMASH Works	AviSynth/VapourSynth и AviUtl, когда нужен выбор между L-SMASH и FFmpeg, индекс .lwi, VFR/CFR и управление потоками.	Нет единого GUI; поведение зависит от хоста и выбранного demuxer.
FFMS2 (FFmpegSource2)	Кадр-точного индексируемого чтения через FFmpeg в AviSynth/VapourSynth с отдельными индексами.	Нет AviUtl-модулей mux/dump/LW48 и нет L-SMASH-пути для MP4/MOV.
BestSource	Современного source-декодирования через FFmpeg с акцентом на точный доступ и скриптовые цепочки.	Не заменяет специализированные AviUtl-компоненты L-SMASH Works.
DGDecNV / DGSource	Аппаратно ускоренного декодирования поддерживаемых форматов в скриптовом видеомонтаже.	Ориентирован на конкретный индексатор/decoder workflow и совместимое GPU-ускорение.
DirectShowSource / DSS2	Быстрого использования системных DirectShow-фильтров и форматов, которые уже корректно открываются установленными splitter/decoder.	Результат зависит от системного filter graph и обычно хуже подходит для воспроизводимого кадр-точного pipeline.

Если требуется воспроизводимый source-фильтр для скриптовой обработки, основное сравнение идёт между L-SMASH Works, FFMS2 и BestSource. L-SMASH Works особенно удобен, когда тот же набор исходников используется и в AviUtl, а MP4/MOV иногда выгодно открыть через L-SMASH. FFMS2 логичен в полностью FFmpeg-ориентированном pipeline. BestSource выбирают, когда подходит его модель индексирования и поддерживаемая среда. DGSource уместен там, где ценность имеет аппаратный decode и workflow DGIndexNV. DirectShowSource — скорее fallback для системного filter graph, а не прямой заменитель индексируемого source в задаче, где важна воспроизводимость.

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

• Плагин не является монтажной программой и не предоставляет единого таймлайна: редактирование выполняет хост.
• Поддержка контейнера не означает поддержку любого кодека внутри; нужны подходящие demuxer и decoder.
• Индекс .lwi связан с конкретным состоянием файла и после изменения исходника должен быть пересоздан.
• Принудительный VFR->CFR добавляет или удаляет кадры и может изменить характер движения.
• Аппаратное декодирование зависит от кодека, профиля, GPU, драйвера и конкретной сборки.
• Muxer и Dumper в AviUtl ограничены семейством ISO Base Media/QuickTime и не являются универсальными контейнерными инструментами.
• Некоторые tolerant seek-режимы могут скрыть ошибку повтором последнего кадра, что нежелательно для точной финальной обработки.

Эти ограничения не делают L-SMASH Works капризным; они следуют из уровня, на котором он работает. Source-фильтр должен интерпретировать временную структуру, выбирать decoder и выдавать кадры в требованиях хоста. Чем больше исходник отклоняется от стандартной структуры, тем больше параметров приходится задавать явно. Именно поэтому диагностика через минимальный software path и новый индекс эффективнее случайного перебора галочек.

Пошаговая настройка без лишних изменений

1. Убедитесь, что L-SMASH Works File Reader действительно загружен хостом.
2. Проверьте приоритеты input plugins и какой reader открывает нужное расширение.
3. Оставьте threads=0, Seek mode=Normal, нативный format, VFR->CFR выключенным, decoder пустым и hardware выключенным.
4. Для LW-Libav включите индекс и дождитесь завершения первого сканирования.
5. Если MP4/MOV открывается некорректно, сравните Libav+L-SMASH и LW-Libav.
6. Только после стабильного software path включайте specific decoder, hardware, forced format или CFR.
7. После изменений, влияющих на индекс, удалите соответствующий .lwi и создайте его заново.

Такой порядок сохраняет причинно-следственную связь. Если изменение одной настройки исправило файл, понятно, какой слой был проблемным. Если же сразу применить чужой пресет с другим decoder, VFR->CFR, кэшем и audio delay, успешный результат нельзя уверенно объяснить, а следующий файл может потребовать противоположных параметров.

Справочник параметров AviSynth

Параметр	Где встречается	Практический смысл
source	Все source-функции	Путь к исходному медиафайлу. Ошибка кодировки или прав доступа выглядит как ошибка открытия, даже если кодек поддерживается.
track	LSMASHVideoSource/AudioSource	Номер дорожки в логике L-SMASH; 0 просит автоматический выбор.
stream_index	LWLibavVideoSource/AudioSource	Индекс потока libavformat; -1 включает автоматический выбор.
threads	Видеоисточники	Количество потоков декодера; 0 — автоматическое значение.
cache	LWLibav	Создание/использование .lwi для точного и повторного доступа.
seek_mode	Видеоисточники	Стратегия обработки фатальной ошибки при seek.
seek_threshold	Видеоисточники	Порог между продолжением декодирования вперёд и новым seek к RAP.
dr	Видеоисточники	Попытка direct rendering для уменьшения копирований при совместимых форматах.
fpsnum/fpsden	Видеоисточники	Целевая дробь CFR при принудительной временной нормализации.
repeat	LWLibav video	Учёт repeat flags/полей в источнике.
dominance	LWLibav video	Порядок полей: по источнику, TFF или BFF.
format	Видеоисточники	Принудительный выходной пиксельный формат.
decoder	Видео/аудио	Список предпочтительных decoder names.
layout	Аудиоисточники	Выходная раскладка каналов.
rate	Аудиоисточники	Выходная частота дискретизации.
av_sync	LWLibavAudioSource	Попытка выравнивания старта аудио относительно видеопотока в индексе.

Параметры с теми же названиями в разных функциях могут иметь близкий смысл, но не всегда одинаковые допустимые значения. Перед переносом скрипта между AviSynth и VapourSynth следует сверить сигнатуру конкретной сборки. Особенно это касается prefer_hw, progress, ff_loglevel, ff_options, fill_audio_gaps и rap_verification: они появлялись в расширенных реализациях и могут отсутствовать в старом бинарном наборе, который всё ещё лежит в каталоге конкретного проекта.

Справочник параметров VapourSynth

Параметр	Назначение	Когда менять
variable	Разрешает variable-format поведение источника.	Только если источник действительно меняет свойства и downstream-фильтры готовы к этому.
cachefile	Явный путь к .lwi.	Когда индекс должен лежать не рядом с исходником.
cachedir	Каталог централизованного кэша.	Для чистых медиапапок, NAS и быстрого локального SSD.
prefer_hw	Выбор/приоритет аппаратного backend.	После проверки стабильного software decode.
ff_loglevel	Уровень сообщений FFmpeg.	Временно при диагностике.
ff_options	Дополнительные key=value для decoder.	Только для конкретной документированной необходимости.
rap_verification	Проверка пригодности RAP на индексации.	Для спорных потоков; после изменения удалить индекс.
repeat	Обработка repeat flags.	Для телесинного/field-coded материала, когда флаги действительно значимы.
dominance	Порядок полей.	При известном неправильном или отсутствующем флаге поля.

VapourSynth особенно чувствителен к согласованности форматов, потому что граф фильтров строится заранее. Если forced format выдаёт один тип, а аппаратный backend способен декодировать только в другой, потребуется промежуточное преобразование. Логичнее сначала получить стабильный VideoNode, затем явно конвертировать его в рабочее пространство с помощью специализированного resize/colorspace-фильтра, где можно контролировать matrix, transfer, primaries и range.

Справочник элементов File Reader в AviUtl

Элемент	Что меняет	Типичная ошибка пользователя
Libav+L-SMASH	Использует L-SMASH demuxer и libavcodec.	Считать его обязательным для любого MP4 и не пробовать LW-Libav при проблеме.
AviSynth Script	Разрешает чтение .avs.	Ожидать работу без установленной/совместимой AviSynth-среды.
VSScript	Разрешает чтение .vpy.	Считать, что File Reader заменяет сам VapourSynth.
LW-Libav	Использует libavformat/libavcodec.	Выключить его и потерять универсальный fallback.
threads	Число decoder threads.	Ставить максимально возможное значение без измерения bottleneck.
Forward threshold	Логика мелкого seek.	Увеличивать очень сильно и замедлять крупные прыжки.
Seek mode	Поведение на ошибке seek.	Использовать tolerant-режим и не замечать повтор последнего кадра.
Video scaler	Chroma upsampling.	Принимать за resize всего кадра.
VFR->CFR	Создаёт равномерную временную сетку.	Включать одинаковые 60000/1000 для любого видео.
Audio delay	Сдвиг звука в сэмплах.	Исправлять им нарастающий drift.
Sampling rate	Ресемплинг звука.	Менять без необходимости и путать с исправлением timestamps.
Channel layout	Выходная схема каналов.	Случайно выполнить downmix или изменить порядок.
A/V sync correction	Коррекция стартового выравнивания.	Ожидать исправления любого вида рассинхрона.
Create Index file	Создание .lwi.	Выключать из-за служебного файла и получать повторное полное сканирование.
Libav video/audio index	Явный выбор stream.	Путать stream_index с track L-SMASH.
LW48 output	Специальный 48-битный YUV-путь.	Включать без lwcolor и совместимого output pipeline.

Когда L-SMASH Works лучше не использовать для конкретного файла

Если специализированный source точно знает структуру формата и даёт более предсказуемый результат, нет необходимости заставлять L-SMASH Works открывать всё. Например, профессиональный RAW/камерный формат может требовать собственного SDK, а повреждённый transport stream — специализированного индексатора. Универсальность LW-Libav сильна, но она не отменяет преимущества format-specific parser там, где важны редкие метаданные, timecode, closed captions или особый field structure.

DirectShow reader может помочь с форматом, который поддерживает установленный системный splitter, но такой fallback делает проект менее воспроизводимым: на другом компьютере filter graph может быть другим. Если проект должен повторяться на нескольких машинах, предпочтительнее явно контролируемый source вроде L-SMASH Works/FFMS2/BestSource или предварительное ремультиплексирование в стандартный контейнер без перекодирования.

Не стоит использовать Muxer L-SMASH Works как замену полноценному кодеру. Muxer собирает уже существующие потоки; он не улучшает качество и не превращает неподдерживаемый codec в совместимый. Если видеопоток не соответствует требованиям целевого MP4/MOV-плеера, нужен encoder или другой container, а не только смена mux.

Как читать сообщения об ошибках

Ошибка failed to import index entries, failed to find first valid frame или близкие сообщения указывают не на интерфейс хоста, а на этап подготовки source. Причины: индекс не соответствует файлу, поток повреждён, decoder не смог начать с ожидаемого RAP, выбран не тот stream или forced decoder несовместим. Начинать следует с удаления индекса и software auto decoder. Если ошибка сохраняется на одном и том же временном участке, вероятно, проблема в самом потоке.

Сообщения FFmpeg о invalid data, missing reference, non-monotonic timestamps или hardware device failure нужно интерпретировать буквально по уровню. Missing reference относится к зависимостям кодека; non-monotonic timestamps — временной структуре контейнера; device failure — аппаратному backend. Не следует лечить timestamp problem сменой video scaler, а hardware failure — Audio delay. Сохранение этой границы между слоями — главное преимущество диагностического подхода к L-SMASH Works.

Если приложение аварийно завершается без сообщения, полезно сначала исключить конфликт разрядностей и несовместимый плагин-хост, затем hardware decoder, затем сторонние input plugins. L-SMASH Works работает внутри процесса или через обвязку хоста, поэтому падение может быть вызвано не только самим source, но и downstream-фильтром, который получил неожиданный формат. Минимальный скрипт, возвращающий только source, помогает отделить эти случаи.

Работа с путями, кэшем и переносом проекта

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

Для сетевого монтажа удобно хранить media на NAS, а cachedir — на локальном SSD. Это уменьшает задержки чтения служебных структур и не требует прав записи рядом с source. Но при работе нескольких пользователей каждый компьютер может строить собственный индекс. Совместный cachedir допустим только если права и механизм именования исключают одновременную запись в один файл; иначе безопаснее локальный кэш на пользователя.

Если каталоги содержат нелатинские имена, в AviSynth нужно отдельно контролировать кодировку скрипта. В VapourSynth Python обычно лучше справляется с Unicode-путями, но внешняя DLL и Windows API всё равно должны быть совместимы. Диагностический перенос проблемного файла в короткий путь вроде D:\test\a.mp4 остаётся простым способом отделить проблемы path encoding от codec/demux.

Выбор между preview и финальной обработкой

Для preview допустимы компромиссы: аппаратный decoder, tolerant seek, уменьшенная точность цветового преобразования или L-SMASH path без индекса, если он быстрее открывает короткий MP4. Для финального encode приоритет другой: воспроизводимый порядок кадров, корректные timestamps, точный stream, согласованный pixel format и отсутствие скрытых повторов при ошибке. Один и тот же проект может использовать разные source-настройки для просмотра и финального рендера, но тогда результат preview не следует считать бит-в-бит эталоном.

Разработчики прямо предупреждают, что LSMASHVideoSource/LibavSMASHSource могут уступать LWLibavVideoSource/LWLibavSource по производительности вне preview. Это важный ориентир: если скрипт долго кодирует фильм, а source построен на L-SMASH, стоит проверить LWLibav с индексом. Если короткий MP4 открывается мгновенно и используется только для навигации, выигрыша от смены пути может не быть.

Частые ошибки настройки и правильные альтернативы

Ошибка	Почему плохо	Что делать
Всегда включать VFR->CFR 60 fps	Файл может быть 23,976/25/29,97 или истинным VFR; кадры будут добавлены/удалены.	Сначала определить временную структуру и требования хоста.
Всегда включать hardware decode	Не все профили и форматы одинаково поддерживаются; возможны копирования и несовместимость.	Проверить software path, затем конкретный backend.
Удалять .lwi как мусор после каждого запуска	Повторная индексация тратит время и может ухудшить отзывчивость.	Хранить индекс или перенести его в cachedir.
Менять Audio delay при дрейфе	Постоянный offset не исправляет нарастающую временную ошибку.	Проверить VFR/CFR, timestamps и sample rate.
Ставить L-SMASH Works первым для всех расширений	Специализированный reader иногда лучше конкретного формата.	Настраивать приоритет по реальному набору plugins.
Принудительно RGB на входе	Лишняя конверсия и риск неверной матрицы/range.	Оставить native format и конвертировать явно позже.
Копировать чужой Preferred decoders	Декодер, полезный для WebM alpha, не нужен другим кодекам.	Оставить пусто и задавать только по конкретной задаче.

Подробно о seek_mode: когда режим восстановления меняет результат

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

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

Aggressive ещё меньше пытается исправлять ошибку. Его практическая роль — временно заставить preview проходить через дефектный участок, чтобы оценить остальную часть файла. Это не режим более быстрого seek. Если переключение на Aggressive неожиданно лечит ролик, следует считать это сигналом о повреждённых пакетах, неверно размеченных точках доступа или нестабильном decoder path, а не подтверждением, что настройка оптимальна.

Ошибки seek часто маскируются длинным GOP. Пользователь прыгает на кадр, который не является ключевым, L-SMASH Works возвращается к предыдущему RAP и декодирует последовательность вперёд. На UHD HEVC или AV1 такой путь может занимать заметное время даже при полностью корректном индексе. В этом случае смена seek_mode ничего принципиально не ускоряет: решением может быть более быстрый decoder, прокси для монтажа или исходник с более коротким GOP.

Отдельно нужно различать seek error и decoder error. Первая группа возникает из-за невозможности правильно позиционироваться в структуре потока, вторая — когда пакет найден, но кодек не может восстановить изображение. Если FFmpeg log показывает missing reference или corrupted frame, проблема ближе к decoder/bitstream. Если ошибка связана с отсутствием ожидаемого index entry или невозможностью найти RAP, проверяют .lwi, контейнерную таблицу и rap_verification.

FFmpeg options и логирование без случайных твиков

ff_options передаёт строку параметров непосредственно в контекст FFmpeg-декодера. Это мощный механизм, но он специально оставлен низкоуровневым: L-SMASH Works не проверяет смысл каждой пары key=value за пользователя. Параметр, уместный для одного decoder, может быть проигнорирован другим или даже сделать его инициализацию невозможной. Поэтому ff_options следует хранить пустым, пока конкретная проблема не подтверждена документацией decoder или диагностическим логом.

Хороший сценарий работы с логом: сначала ff_loglevel=4, чтобы увидеть warnings без огромного потока отладочных сообщений. Если предупреждение не раскрывает причину, временно перейти к debug. Trace полезен лишь в узкой диагностике, потому что объём сообщений может быть очень большим. После нахождения причины уровень возвращают к тихому, иначе логирование само начинает влиять на удобство работы и скорость вывода консоли.

При аппаратном декодировании лог особенно ценен: он показывает попытку создания device context, выбранный pixel format и причины fallback. Режим prefer_hw, который перебирает несколько backend, может молча перейти к software decoder, если аппаратный путь недоступен. Если задача требует именно GPU-декодирования, одного факта успешного открытия файла недостаточно — следует убедиться в логе или свойствах окружения, какой decoder реально активирован.

В противоположной ситуации пользователь может принудительно указать h264_qsv или hevc_qsv в decoder и получить ошибку на системе без подходящего Intel Media SDK/oneVPL окружения. То же относится к CUVID/NVDEC и DirectX backend. Универсальная диагностика — очистить decoder и prefer_hw, подтвердить software decode, а затем включить один аппаратный вариант. Так сразу видно, является ли проблема специфичной для GPU.

ISO Base Media и QuickTime: почему L-SMASH особенно важен для MP4/MOV

MP4 и MOV состоят из иерархии boxes/atoms. Внутри находятся описания дорожек, timescale, sample descriptions, таблицы размеров и смещений samples, mapping от decode time к composition time, sync samples, edit lists и другие данные. Для кадр-точного source недостаточно прочитать только mdat с медиаданными: нужно корректно интерпретировать таблицы, чтобы понять порядок декодирования и отображения. L-SMASH создавался именно вокруг этой модели контейнера, поэтому L-SMASH path способен работать с ней напрямую.

Composition time особенно важен для кодеков с B-кадрами. Порядок пакетов в файле может соответствовать декодированию, а порядок отображения — другой. Если источник перепутает DTS и PTS, визуально это проявится перестановкой кадров или ошибочной длительностью. L-SMASH Works скрывает эту механику за обычным вызовом source, но при нестандартном файле понимание структуры помогает объяснить, почему два demuxer могут вести себя по-разному.

Edit list способен задавать начальный сдвиг, пропуск части media timeline или пустой участок до первого sample. Отсюда возникают случаи, когда аудио и видео физически начинаются в файле в разных местах, но при корректной интерпретации проигрываются синхронно. Простое удаление такого metadata ремультиплексером может изменить начало. Поэтому при рассинхроне MP4/MOV полезно сравнивать Libav+L-SMASH и LW-Libav: различие иногда связано именно с обработкой edit list и timestamp normalization.

L-SMASH Works Dumper полезен в таких случаях, потому что текстовый dump показывает структуру boxes без необходимости писать собственный parser. Пользователь может проверить, есть ли несколько trak, присутствует ли edts/elst, как устроена sample table и где расположен moov. Это не средство автоматического ремонта, но хороший способ подтвердить, что необычное поведение связано с контейнерной разметкой.

Optimize for Progressive Download в Muxer работает с этой же моделью. Если moov находится в конце, потоковый клиент должен дождаться конца файла, прежде чем получить все таблицы. Перемещение необходимых метаданных к началу позволяет начать воспроизведение раньше. Никакие кадры при этом не становятся лучше и codec не меняется: перестраивается расположение контейнерных данных.

Разделение container, codec и pixel format при поиске проблемы

Уровень	Что может сломаться	Как проверить
Контейнер	Неверные offsets, edit list, timestamps, stream map, повреждённые boxes.	Сравнить demuxer, посмотреть dump/metadata, попробовать ремультиплексирование без перекодирования.
Кодек	Неподдерживаемый profile, битые reference frames, нестабильный hardware decoder.	Отключить hardware и forced decoder, включить FFmpeg warnings/debug.
Временная модель	VFR, repeat flags, неправильный CFR target, non-monotonic PTS.	Выключить VFR->CFR/repeat, пересоздать индекс, сравнить timecodes.
Pixel format	Неподдерживаемая битность, неправильный range/matrix, потеря alpha.	Оставить native format, затем конвертировать отдельно и явно.
Хост	Другой input plugin перехватил расширение, несовместимая разрядность, фильтр не принимает формат.	Проверить plugin information, приоритет и минимальный source-only проект.

Такое разделение особенно полезно, когда один и тот же файл открывается в медиаплеере, но не открывается в AviUtl. Плеер может использовать совершенно другой splitter, decoder и стратегию исправления ошибок. Факт воспроизведения доказывает только то, что какая-то цепочка смогла показать файл, но не гарантирует кадр-точного доступа в L-SMASH Works. И наоборот, source может открыть поток, который плеер отвергает из-за более строгих требований интерфейса.

Минимальный source-only тест в AviSynth/VapourSynth исключает большую часть хостовой логики. Если короткий скрипт с LWLibavSource работает, а полный проект падает, проблема вероятнее в downstream-фильтре, памяти или несовместимом формате. Если source-only тоже падает, зона поиска сужается до файла, decoder, index и самой source-конфигурации.

Кадровая точность и что она реально означает

Кадр-точный seek означает, что запрос кадра N возвращает именно тот декодированный кадр, который соответствует позиции N в принятой временной модели. Для CFR это обычно выглядит просто, но B-frames, open GOP, repeat flags и VFR усложняют соответствие. Индекс нужен для того, чтобы быстро переходить к правильной decode position, однако сам индекс не может исправить битстрим, в котором отсутствуют необходимые reference frames.

Для VFR номер кадра и время — разные сущности. Два соседних кадра могут иметь интервалы 16 и 40 мс, поэтому кадр 1000 не обязательно соответствует 1000/fps секунд. Если затем принудительно создать CFR, L-SMASH Works выбирает кадры для новой сетки, и номера после преобразования относятся уже к другой последовательности. Это важно при переносе cut list и timecodes между VFR и CFR workflow.

При работе с внешними субтитрами или EDL лучше ориентироваться на время или timecode, если исходник VFR. Если список нарезки задан номерами кадров из другого reader, даже два кадр-точных источника могут расходиться, если один применил repeat flags или CFR, а другой нет. Перед пакетной обработкой полезно проверить несколько контрольных времён в начале, середине и конце материала.

Пакетная обработка нескольких файлов

L-SMASH Works хорошо подходит для скриптовой автоматизации, но при пакетной работе проявляются организационные вопросы. Каждый новый LWLibav-источник может строить индекс, поэтому первая обработка десятков файлов включает существенный подготовительный этап. Если pipeline запускается повторно, сохранение cachedir на быстром SSD окупается. Если файлы одноразовые и после рендера удаляются, можно очищать индексный каталог по завершении всей задачи, а не каждого файла.

В AviSynth удобно вынести общие параметры в функцию-обёртку: decoder policy, cache, pixel format и обработку звука. В VapourSynth можно сделать Python-функцию, которая сначала вызывает core.lsmas.LWLibavSource, затем проверяет свойства и приводит clip к рабочему формату. Это уменьшает риск, что двадцать скриптов будут использовать слегка разные fpsnum или prefer_hw.

Но автоматизация не должна скрывать stream selection. Если каталог содержит смесь файлов с разным количеством дорожек, жёсткий stream_index=1 может означать в одном файле английский звук, а в другом commentary или вообще видео. Для надёжного batch сначала анализируют stream metadata, затем выбирают индекс по codec_type, language/disposition или другим критериям, а L-SMASH Works получает уже вычисленное значение.

При параллельной пакетной обработке central cachedir должен выдерживать одновременную запись. Лучше, чтобы каждый процесс создавал независимый .lwi для своего source. Запуск нескольких экземпляров на один и тот же несуществующий индекс может вызвать конкуренцию. Если workflow допускает, сначала последовательно прогревают индексы, затем запускают параллельный encode.

Как оценивать аппаратный decode в реальном pipeline

Сравнивать только процент загрузки CPU недостаточно. Аппаратный decoder может снизить CPU, но добавить копирование device→host. Если затем применяются AviSynth-фильтры, которые работают только в системной памяти, каждую frame surface всё равно приходится выгружать. На лёгком H.264 это иногда медленнее чистого software decode; на тяжёлом 4K HEVC/AV1 выигрыш чаще заметен. Решение зависит от полной цепочки.

В VapourSynth часть filters тоже может иметь GPU-версии, но L-SMASH Works обычно выдаёт обычные кадры в формате, совместимом с VapourSynth. Аппаратный decode здесь не означает zero-copy GPU graph. Если нужен настоящий device-resident pipeline, следует проверить возможности конкретных plugins и API; один prefer_hw эту задачу не решает.

Ещё один фактор — одновременный encode. Если конечный кодер тоже использует GPU, декодирование и кодирование могут конкурировать за один hardware engine или memory bandwidth. Иногда выгоднее оставить decode на CPU, а GPU отдать encoder. Поэтому оптимизация должна измерять время всего задания, а не только скорость source.

Работа с альфа-каналом и необычными форматами изображения

Наличие alpha в контейнере и codec не гарантирует, что он дойдёт до хоста. Декодер должен уметь извлечь прозрачность, L-SMASH Works — представить соответствующий pixel format, а AviSynth/VapourSynth/AviUtl — не отбросить его при преобразовании. WebM VP8/VP9 alpha — типичный пример, где preferred decoder может иметь значение. Но принудительное YUV420 без alpha уничтожит прозрачность ещё до фильтров.

Для проверки alpha лучше использовать тестовый clip с очевидно прозрачной областью и смотреть planes/props, а не только визуальный preview на чёрном фоне. Если alpha отсутствует уже на source, меняют decoder. Если source отдаёт alpha, но она исчезает после resize/colorspace, проблема ниже по цепочке. Такой подход точнее, чем одновременно менять Preferred decoders и настройки вывода.

С профессиональными 10/12-битными кодеками действует та же логика. Forced format может привести материал к 8 бит и скрыть, что decoder исходно выдавал более высокую точность. Если конечная обработка рассчитана на high bit depth, проверяют bit depth сразу после source и только затем строят конверсию.

Сценарий восстановления проблемного MP4 без перекодирования

1. Сделать копию исходника и не работать с единственным экземпляром.
2. Проверить чтение через LW-Libav с новым индексом и software decoder.
3. Проверить Libav+L-SMASH, чтобы сравнить интерпретацию ISO BMFF.
4. Если один demuxer читает, а другой нет, сохранить diagnostic dump структуры контейнера.
5. При подозрении на повреждённые таблицы выполнить ремультиплексирование инструментом, который перепишет контейнер без перекодирования потоков.
6. Для полученного файла удалить старый .lwi и построить новый.
7. Сравнить длительность, начало аудио, несколько seek-позиций и конец файла.

Ремультиплексирование не лечит повреждённые coded frames, но способно пересобрать таблицы samples и метаданные. Если после remux ошибки остаются в тех же кадрах, проблема вероятнее в битстриме. Если исчезают — контейнерная структура была частью причины. L-SMASH Works полезен здесь как контрольный reader и как источник диагностической информации, но сам не должен восприниматься как автоматический repair tool.

Сценарий проверки синхронизации аудио и видео

Для постоянного сдвига выбирают несколько визуальных/звуковых событий в начале и конце. Если разница одинаковая, это offset: можно использовать Audio delay или корректно учесть старт потоков. Если разница растёт, это drift: проверяют CFR fraction, VFR timestamps и sample rate. Если разница скачет после конкретного места, подозревают discontinuity, повреждённые timestamps или пропущенные packets.

A/V sync correction полезна только в первом классе задач, когда надо правильно совместить начало потоков по данным индекса. Она не может исправить drift из-за 60 против 60000/1001 и не восстановит потерянные аудиопакеты. Такой принцип позволяет избежать распространённого цикла, когда пользователь меняет Audio delay после каждого десятка минут материала, но никогда не устраняет исходную временную ошибку.

Для точного контроля можно выгрузить timecode v2 для видео, сравнить длительность последнего timestamp с длительностью audio samples и проверить start time. Если видео VFR, средний fps — только статистика и не должен заменять реальные timestamps в расчёте синхронизации.

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

• Исходный файл перезаписан или заменён другим файлом под тем же именем.
• Файл ремультиплексирован, даже если видео и аудио не перекодировались.
• Изменён rap_verification или другая политика, влияющая на индексирование.
• Появились неожиданные seek-ошибки после переноса/восстановления проекта.
• Индекс создан другой несовместимой сборкой и поведение стало подозрительным.
• Контейнер был частично скачан, а затем дописан до полного состояния.

Удаление .lwi безопасно для исходника: индекс будет построен заново. Но это может занять время, поэтому не нужно удалять индексы профилактически перед каждым запуском. Если файл неизменен и индекс работает, его повторное использование — одна из причин выбирать LWLibav.

Что сохранять вместе с проектом

Для воспроизводимости важнее сохранить исходные media, скрипты и значения параметров L-SMASH Works, чем сам .lwi. Индекс является производным кешем. Если проект зависит от конкретного stream_index, decoder, CFR fraction или channel layout, эти параметры должны быть в скрипте либо документированы в настройках проекта. Тогда на другой машине индекс можно построить заново и получить тот же логический source.

Если используется AviUtl, полезно фиксировать скрин или текст настроек File Reader и порядок input plugins, потому что эти параметры хранятся отдельно от содержимого media. Проект, который открылся другим reader из-за изменившегося приоритета, может визуально отличаться даже при тех же файлах. В скриптовых средах эта проблема меньше, потому что source-функция и параметры явно записаны в .avs/.vpy.

Контрольный список перед финальным рендером

Проверка	Зачем
Нужный stream/track выбран явно	Исключает случайный выбор commentary, preview или альтернативной дорожки.
.lwi соответствует текущему файлу	Предотвращает seek и length ошибки из старого индекса.
VFR->CFR используется только при необходимости	Сохраняет исходную временную модель и избегает лишних duplicate/drop frames.
Hardware decode проверен против software	Исключает backend-specific ошибки и расхождения формата.
Pixel format и bit depth осознанны	Предотвращает раннее уменьшение точности или потерю alpha.
Начало и конец A/V синхронны	Выявляет drift, который не видно по первой минуте.
Seek mode не маскирует ошибки	Не допускает повтор последнего кадра в мастер-рендере.
File Reader действительно используется AviUtl	Гарантирует, что проверенные настройки относятся к фактическому reader.

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

Итоговая схема выбора режима

Для MP4/MOV начните с LW-Libav, если проект требует многократного точного seek и долгой обработки; сравните Libav+L-SMASH, если нужен быстрый preview или конкретный файл лучше разбирается L-SMASH. Для MKV/WebM/TS и большинства других контейнеров основной путь — LW-Libav. Для VFR не включайте CFR без требования downstream. Для многодорожечных файлов выбирайте stream явно. Для нестабильного аппаратного decode вернитесь к software. Для изменённого исходника удалите индекс. Для постоянного аудиосмещения используйте delay только после проверки временной базы.

В результате L-SMASH Works наиболее полезен не как чтение всех форматов одной кнопкой, а как управляемый source-слой. Он позволяет выбрать demuxer, decoder, stream, временную модель, индексирование и выходной формат именно там, где автоматический импорт хоста недостаточно прозрачен. Чем точнее определена задача — preview, кадр-точный монтаж, VFR, многодорожечный контейнер, аппаратный decode, извлечение timecodes или MP4 mux — тем меньше настроек приходится менять и тем воспроизводимее получается весь pipeline.