av1an помогает перекодировать видео с параллельной обработкой сцен: программа находит границы сцен, делит исходник на независимые фрагменты, запускает несколько экземпляров выбранного кодировщика, при необходимости подбирает качество по VMAF, SSIMULACRA2, Butteraugli или XPSNR, обрабатывает кадры через FFmpeg или VapourSynth и собирает готовый файл с аудиодорожками и субтитрами.

Работа строится вокруг одной команды с входным файлом, выходным путём и набором параметров. av1an сам организует разбиение на сцены и очередь фрагментов, но непосредственно сжимают видеопоток внешние кодировщики: aomenc, SvtAv1EncApp, rav1e, vpxenc, x264 или x265. Поэтому результат зависит не только от настроек av1an, но и от возможностей выбранного кодировщика, FFmpeg, VapourSynth и установленных плагинов.

Для типичной задачи достаточно указать исходник и выходной файл, после чего проверить выбранный кодировщик и способ нарезки. Более сложные схемы добавляют число рабочих процессов, FFmpeg-фильтры, параметры звука, файл сцен, зоны с разными настройками, Target Quality и способ объединения чанков. Такой подход особенно полезен на многоядерных процессорах, когда один экземпляр кодировщика загружает систему хуже, чем несколько независимых процессов.

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

Внутри рабочего процесса av1an не заменяет видеокодек и не пытается реализовать собственный универсальный энкодер. Его задача — подготовить структуру кодирования, определить границы, раздать фрагменты нескольким рабочим процессам, следить за их завершением и собрать результат. Именно поэтому в сообщениях терминала одновременно встречаются сведения о сценах, очереди, количестве workers, скорости и аргументах внешнего кодировщика. Если сравнивать с прямым запуском SvtAv1EncApp или aomenc, главное отличие состоит в оркестрации: один исходный ролик превращается в набор независимо обрабатываемых участков.

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

Программа не содержит монтажной временной шкалы и не предназначена для ручной расстановки клипов. Обрезка, масштабирование и другие преобразования выполняются как FFmpeg-фильтры, применяемые к каждому кодируемому сегменту. Из этого следует практическое правило: сначала определить, нужен ли вообще монтаж, а уже затем использовать av1an для массового кодирования готового видеоряда. Если требуется визуально переставлять сцены, делать многодорожечный монтаж или рисовать маски, понадобится редактор или отдельный подготовительный этап.

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

Упрощённо процесс можно представить как последовательность из анализа исходника, поиска сцен, подготовки точных диапазонов кадров, постановки чанков в очередь, параллельного кодирования и финального объединения. На практике часть шагов меняется в зависимости от выбранного chunk method. Методы на базе VapourSynth получают точные диапазоны через соответствующие источники, а варианты на базе FFmpeg используют собственные способы выбора или предварительного сегментирования. Поэтому два запуска с одинаковым кодировщиком способны различаться по нагрузке на диск и скорости декодирования ещё до начала собственно сжатия.

Для пользователя важнее всего понимать границы ответственности. av1an формирует команду и контролирует рабочие процессы, FFmpeg или VapourSynth подают кадры, выбранный encoder формирует видеопоток, а ffmpeg, mkvmerge либо внутренний IVF-объединитель создают итоговый контейнер. Ошибка в одном звене часто выглядит как сообщение av1an, хотя первопричина находится во внешней утилите. Поэтому при диагностике полезно читать не только последнюю строку, но и stderr конкретного энкодера или источника кадров.

Такой конвейер удобен для воспроизводимых задач. Параметры можно хранить в скриптах, запускать одну и ту же схему для серии файлов и менять только вход/выход. Однако av1an сам по себе не предоставляет визуальный менеджер библиотеки или форму с пресетами устройств. Автоматизация достигается средствами командной оболочки, пакетными файлами, shell-скриптами, задачами CI или другой системой, которая вызывает av1an с нужными аргументами.

Поддерживаемые кодировщики и кодеки

В параметре encoder доступны aom, rav1e, vpx, svt-av1, x264 и x265. Соответственно, av1an может организовать кодирование AV1 через aomenc, rav1e или SvtAv1EncApp, VP8/VP9 через vpxenc, H.264/AVC через x264 и H.265/HEVC через x265. Важно различать имя, которое принимает av1an, и исполняемый файл кодировщика: например, значение svt-av1 подразумевает доступный SvtAv1EncApp. Наличие только библиотечной части кодека недостаточно — av1an должен иметь возможность запустить конкретный executable.

Если encoder не указан, документация CLI задаёт svt-av1 как базовый выбор. Это не означает, что SvtAv1EncApp автоматически появляется в системе. Перед запуском стоит проверить, что исполняемый файл доступен по PATH или иным способом, предусмотренным окружением. Ошибка вида encoder not found почти всегда означает проблему обнаружения внешнего бинарника, а не неподдерживаемый входной контейнер.

Параметры видео после -v или --video-params адресуются непосредственно выбранному кодировщику. Их синтаксис поэтому отличается от FFmpeg. Нельзя механически взять строку вроде -crf из команды ffmpeg и ожидать того же поведения в x264/x265 или SvtAv1EncApp: нужно ориентироваться на справку самого encoder binary. av1an добавляет собственный набор параметров по умолчанию, а --no-defaults позволяет отказаться от их слияния, если требуется полностью контролировать строку энкодера.

Входные файлы и VapourSynth

Обычный вход задаётся через -i или --input. В качестве источника можно использовать видеофайл, а также VapourSynth-скрипт. Скриптовый вход полезен там, где подготовка кадров уже описана фильтрами VapourSynth: дебандингом, ресайзом, сложным денойзингом, кадровыми преобразованиями или собственной цепочкой источника. av1an в таком случае остаётся оркестратором и получает кадры из подготовленного скрипта, а не пытается повторить его фильтры внутри себя.

Для тяжёлого VapourSynth-проекта предусмотрен proxy input. Прокси должен содержать то же количество кадров, что и фактический источник. Его можно использовать для определения сцен и Target Quality, чтобы не выполнять дорогой скрипт повторно на аналитических этапах. Это особенно полезно, когда исходная цепочка фильтров значительно медленнее обычного декодирования. Несовпадение числа кадров между прокси и реальным входом, напротив, разрушает соответствие сцен и делает такой приём непригодным.

При работе со скриптом нужно отдельно следить за доступностью VSScript и VapourSynth-плагинов. av1an способен стартовать, но конкретный chunk method или метрика не заработает, если необходимый компонент не загружается. В актуальных отчётах об ошибках встречаются случаи, когда активация Python virtual environment меняла доступность VSScript API. Практический способ проверки — сначала убедиться, что VapourSynth и нужные плагины видны в том же окружении, из которого запускается av1an.

Поиск сцен: standard и fast

Метод split-method av-scenechange анализирует видео и ищет кадры, с которых начинаются новые сцены. Альтернатива none полностью отключает автоматический анализ, оставляя только дополнительные разрезы, заданные через extra-split. Это полезно для тестов или специальных источников, где автоматическая граница не нужна. Список сцен можно сохранить в JSON и затем использовать повторно, а --sc-only позволяет выполнить только определение сцен и завершить работу.

Для самого анализа доступны режимы standard и fast. Standard описан как наиболее точный при приемлемой скорости и использует стоимостной алгоритм для выбора ключевых кадров. Fast сравнивает необработанную разницу пикселей, поэтому работает быстрее, но может хуже определять смысловые переходы. Выбор зависит от того, насколько дорог анализ относительно общего кодирования: на очень медленном энкоде экономия нескольких минут поиска сцен почти не влияет на итоговое время, а ошибки границ могут изменить распределение чанков.

Параметр sc-downscale-height уменьшает высоту изображения только для анализа сцен. Снижение разрешения ускоряет поиск, но документация прямо предупреждает о падении точности, особенно при сильном уменьшении. sc-pix-format задаёт пиксельный формат анализа. Эти настройки полезны для оптимизации больших 4K/8K источников, но их лучше менять осознанно: алгоритму нужны различия кадров, и чрезмерное упрощение изображения способно стереть тонкие переходы.

Дополнительные разрезы и минимальная сцена

Даже если естественная сцена длится несколько минут, держать её одним чанком невыгодно: один worker может остаться занят после завершения всех остальных. Поэтому av1an умеет добавлять границы по максимальной длине. --extra-split задаёт длину в кадрах, а --extra-split-sec — в секундах. Если указаны оба параметра, приоритет имеет значение в кадрах. По документации для секунд используется базовое значение 10, если пользователь не переопределил его и не выбрал кадры.

--min-scene-len задаёт минимальное число кадров для разреза. Это защита от чрезмерно коротких сцен, которые создают большое число мелких заданий и накладные расходы. Базовое значение — 24 кадра. Для материала с частыми вспышками, клиповым монтажом или анимационными вставками можно получить много близких границ, и увеличение минимума иногда делает очередь стабильнее. Но слишком большое значение способно объединить действительно разные сцены и уменьшить естественность сегментации.

--force-keyframes принимает список номеров кадров через запятую и позволяет принудительно использовать их как границы/ключевые кадры. Это инструмент для заранее известных точек, например начала глав или результатов внешнего анализа. Он не заменяет ручной монтаж: кадры не удаляются и не переставляются. Параметр лишь влияет на структуру кодирования и точки разделения.

Workers и загрузка процессора

Опция -w или --workers определяет число параллельных рабочих процессов. Значение 0 означает автоматический выбор. Идея av1an состоит не в том, чтобы безусловно запускать worker на каждый логический поток, а в том, чтобы подобрать несколько независимых кодировщиков так, чтобы суммарно они лучше использовали CPU. Один SvtAv1EncApp и один aomenc по-разному масштабируются по потокам, поэтому универсального числа workers для всех кодеков и пресетов нет.

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

--set-thread-affinity привязывает каждый worker к набору потоков заданного размера. Эта функция поддерживается в Linux и Windows; на других системах параметр не даёт эффекта. Привязка может уменьшить миграцию рабочих процессов между ядрами и сделать поведение стабильнее, но требует согласовать число threads внутри кодировщика с размером выделенного набора. Неверная комбинация способна, наоборот, ухудшить загрузку.

Порядок чанков и время простоя

--chunk-order отвечает за порядок выдачи заданий. long-to-short ставит самые длинные куски первыми и является базовым вариантом. Логика проста: тяжёлые сцены начинают обрабатываться заранее, поэтому к концу работы меньше вероятность, что весь процесс ждёт один огромный хвост. Для максимальной загрузки многоядерного CPU это обычно разумный стартовый порядок.

short-to-long делает обратное и начинает с коротких частей. sequential сохраняет порядок появления сцен в видео, что удобно для наблюдения за прогрессом в естественной последовательности. random перемешивает чанки; документация отмечает, что такой порядок даёт более репрезентативную оценку будущего размера файла на ранней стадии, потому что первые закодированные куски представляют разные части материала.

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

Параметры кодировщика и --no-defaults

Строка --video-params передаётся encoder binary. av1an при этом может дополнять её собственными параметрами по умолчанию, зависящими от выбранного энкодера. Если пользователь хочет исключить это поведение, используется --no-defaults. Этот флаг особенно важен при сравнительных тестах: без него одинаковая внешне команда может фактически включать дополнительные настройки av1an, а выводы о скорости или качестве будут относиться не к чистой строке энкодера.

Передача параметров требует аккуратного экранирования, потому что одна командная строка содержит аргументы другой программы. На POSIX-оболочках и в PowerShell правила кавычек различаются. Для длинных наборов параметров удобнее сначала добиться запуска с минимальной строкой, затем добавлять опции группами. Если ошибка говорит expected one argument, часто проблема возникает до старта кодировщика: оболочка разделила значение --video-params или --ffmpeg на несколько аргументов.

Не стоит смешивать пространства имён. --ffmpeg принимает FFmpeg-видеофильтры, --audio-params — FFmpeg-настройки аудио, а --video-params — синтаксис выбранного encoder binary. Например, параметр качества SvtAv1EncApp или aomenc должен быть написан именно так, как его понимает соответствующий executable. Это одно из главных мест, где пользователи, привыкшие к одному только ffmpeg, получают неожиданные ошибки.

Один или два прохода

--passes принимает 1 или 2. Для большинства энкодеров базово используется один проход, но aom и vpx в нережимном варианте могут автоматически работать в два прохода. Документация отдельно отмечает, что aom и vpx получают пользу от двухпроходной схемы даже в режиме постоянного качества, тогда как у других кодировщиков two-pass чаще связывают с более точным управлением VBR.

У aom и vpx режим RT поддерживает только один проход, поэтому заданное пользователем значение two-pass там не применяется. Это пример, почему итоговую команду следует оценивать в контексте конкретного encoder binary. av1an не может заставить внешний кодировщик поддерживать комбинацию, которую тот сам не реализует.

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

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

--pix-format задаёт формат пикселей, который используется при кодировании; базовое значение в документации — yuv420p10le. Это 10-битный YUV 4:2:0. Пользователь может выбрать другой допустимый FFmpeg pixel format, например yuv420p или yuv444p, если выбранный кодировщик, исходник и конечная задача его поддерживают. Нельзя считать, что более высокая разрядность или 4:4:4 автоматически дают пользу: формат должен соответствовать исходным данным и совместимости проигрывателей.

--pix-format-converter выбирает способ конвертации pixel format для обычного видеовхода. Доступны ffmpeg и встроенная функция resize VapourSynth; базово используется ffmpeg. Параметр не управляет преобразованием формата для Target Quality, поэтому при сложной схеме важно не путать эти два этапа.

Отдельный --sc-pix-format относится только к поиску сцен. Таким образом, один запуск может анализировать границы в более простом формате, кодировать в 10-битном формате и считать метрику с отдельными настройками разрешения. Такая независимость удобна для оптимизации, но увеличивает число мест, где возможно несоответствие. При диагностике цветовых или глубинных проблем лучше временно упростить цепочку и проверить каждый этап отдельно.

FFmpeg-фильтры: масштабирование и кадрирование

Параметр -f или --ffmpeg предназначен для видеofilter arguments FFmpeg. Документация приводит два типовых сценария: crop и scale. Фильтр применяется к сегментам перед передачей кадров в кодировщик, поэтому можно изменить разрешение или вырезать область кадра без отдельного промежуточного файла. При этом av1an не превращается в визуальный редактор: координаты и размеры задаются текстом, а правильность результата следует предварительно проверить коротким тестом.

Кадрирование особенно важно согласовать с измерением качества. Если Target Quality или VMAF сравнивает закодированный кадр с исходным, обе стороны метрики должны иметь совместимую геометрию. Для этого предусмотрены параметры фильтра метрики и разрешения. Если обрезать только кодируемую ветку, сравнение с необрезанным reference либо завершится ошибкой, либо будет методологически неверным.

Для сложной цепочки FFmpeg разумно сначала проверить сам фильтр отдельно в ffmpeg, затем перенести его в --ffmpeg. Так легче отделить синтаксическую ошибку фильтра от особенностей экранирования аргумента av1an. В Windows особенно полезно избегать лишних уровней кавычек и начинать с одной простой операции, потому что PowerShell и cmd по-разному обрабатывают вложенные строки.

Аудио и субтитры

--audio-params использует синтаксис FFmpeg. Если параметр не задан, документация указывает -c:a copy, то есть аудиодорожки копируются без повторного кодирования. Это экономит время и исключает дополнительную потерю качества. Если нужно перекодировать звук, можно задать codec, bitrate и другие параметры FFmpeg для каждой дорожки.

Внутри --audio-params не следует использовать -map. Вместо этого документация рекомендует stream specifiers с двоеточиями для конкретных аудиопотоков. Такой подход позволяет, например, первую дорожку кодировать в Opus, а вторую — в AAC с отдельными параметрами. Субтитры по умолчанию копируются. Это важно учитывать при выборе контейнера: итоговый muxer и формат должны поддерживать требуемые дорожки.

Работа со звуком происходит отдельно от параллельного видеокодирования, поэтому ускорение чанков не означает, что аудио тоже разбивается на те же workers. Если финальная сборка сообщает проблему с временными метками или seeking, следует проверить не только encoder, но и метод concat. Документация прямо отмечает случаи, когда FFmpeg concatenation может давать частично нарушенный поиск по аудио, и рекомендует mkvmerge, когда нужен Matroska.

Chunk method: зачем нужен отдельный выбор

Chunk method определяет, каким способом точный диапазон кадров подаётся выбранному энкодеру. Это один из самых технически значимых параметров av1an, потому что он влияет на точность границ, скорость декодирования, требования к плагинам и объём временных файлов. Базовая таблица CLI показывает lsmash, но подробная документация уточняет, что av1an выбирает первый доступный метод по приоритету lsmash, ffms2, dgdecnv, bestsource, hybrid.

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

BestSource позиционируется как самый точный, но медленный вариант с линейным декодированием. Он полезен как резервный путь для сложного исходника, когда важнее корректность, чем скорость подготовки чанков. Выбор метода следует делать по реальному типу файла: быстрый энкодер на лёгком материале может упираться именно в декодирование, тогда как при медленном AV1-пресете разница между source methods станет менее заметна.

DGDecNV и ограничения аппаратного декодирования

dgdecnv требует VapourSynth-плагин, доступный dgindexnv и NVIDIA GPU с поддержкой CUDA video decoding. Документация описывает метод как очень быстрый, но ограничивает поддерживаемые входные кодеки AVC, HEVC, MPEG-2 и VC1. Поэтому наличие совместимой NVIDIA-карты само по себе не означает, что dgdecnv подходит для любого исходника.

Аппаратное декодирование здесь относится к получению кадров для чанков, а не к GPU-кодированию финального видео. Список поддерживаемых encoder values av1an состоит из aomenc, rav1e, vpxenc, SvtAv1EncApp, x264 и x265; это отдельные программные кодировщики. Нельзя интерпретировать поддержку DGDecNV как встроенный NVENC-путь. Если нужен именно аппаратный видеокодер NVIDIA, av1an не предоставляет его как штатное значение --encoder.

При выборе dgdecnv стоит учитывать полную цепочку: индексатор должен находиться в PATH, плагин — загружаться VapourSynth, а исходный видеокодек — входить в поддерживаемый набор. Если любой пункт не выполнен, проще вернуться к lsmash, ffms2, bestsource или FFmpeg-методам, чем искать ошибку в параметрах самого энкодера.

FFmpeg-методы hybrid, select и segment

hybrid сочетает segment и select. Он использует FFmpeg, обычно даёт точные диапазоны, но создаёт промежуточные файлы, которые могут занимать много места. Чтобы не декодировать лишний материал с самого начала, метод ищет ближайший ключевой кадр до нужной позиции и декодирует небольшой участок до запрошенного диапазона. Это хороший резерв, когда VapourSynth-плагины недоступны.

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

segment создаёт куски по ключевым кадрам исходника. Он быстрый как концепция, но границы не являются frame-exact, потому что резать можно только по существующим keyframes. Метод также создаёт промежуточные файлы. Для задач, где точное соответствие сцен и кадров важно для Target Quality или последующего сравнения, это ограничение нужно учитывать заранее.

Объединение результата: mkvmerge, FFmpeg и IVF

После кодирования чанки нужно собрать в один выходной файл. --concat принимает ffmpeg, mkvmerge или ivf. Документация считает mkvmerge обычно лучшим способом, поскольку он избегает отмеченных проблем FFmpeg с аудиопоиском и отдельными настройками keyframe filtering. Цена — только Matroska и обязательное наличие mkvmerge.

FFmpeg concatenation способен выводить контейнеры помимо MKV, включая WebM. Поэтому, если нужен WebM, расширение выходного файла и concat через FFmpeg могут быть необходимы. Одновременно документация предупреждает, что FFmpeg иногда создаёт файл с частично проблемным audio seeking. Такой дефект лучше проверять перемоткой в нескольких местах, а не только успешным воспроизведением с начала.

ivf — экспериментальный внутренний способ объединения. IVF подходит только для VP8, VP9 и AV1 и не поддерживает аудио. Его следует воспринимать как специализированный видеопотоковый вариант, а не универсальный контейнер для готового фильма. Для обычного результата с несколькими аудиодорожками и субтитрами Matroska через mkvmerge остаётся наиболее предсказуемой схемой.

Target Quality: цель вместо одного CRF

Target Quality решает другую задачу, чем фиксированное значение CRF/CQ на весь ролик. av1an делит материал на сегменты, делает пробные кодирования и подбирает параметр качества для каждого участка так, чтобы метрика приблизилась к целевому уровню. Сложные сцены при этом могут получить больше битов, а простые — меньше. Цель — более ровное визуальное качество и уменьшение перерасхода там, где высокий битрейт не даёт заметной пользы.

Режим требует, чтобы выбранный encoder работал в constant-quality схеме, где av1an может менять quantizer/quality parameter по сегментам. Параметр --target-quality задаёт целевое число, а --target-metric выбирает метрику. Это не магический пресет: результат зависит от кодека, содержимого, диапазона q, разрешения probes и точности выбранной метрики.

Количество probes по документации базово равно четырём. Больше проб может дать алгоритму больше информации о зависимости качества от q, но увеличивает время. Параметры min-q и max-q ограничивают область поиска. Практически полезно сначала убедиться, что обычное кодирование этим encoder работает, затем включить Target Quality без дополнительных фильтров, и только потом усложнять систему.

VMAF, SSIMULACRA2, Butteraugli и XPSNR

В Target Quality поддерживаются VMAF, SSIMULACRA2, Butteraugli и XPSNR. Набор зависимостей различается. Для VMAF нужен FFmpeg с libvmaf и подходящей моделью. SSIMULACRA2 можно рассчитывать через VapourSynth HIP либо Zig Image Process при совместимом chunk method. Butteraugli поддерживается через HIP или julek, а XPSNR — через FFmpeg libxpsnr либо VapourSynth Zig в предусмотренных режимах.

Выбор метрики должен соответствовать инфраструктуре. Если FFmpeg собран без нужного фильтра, включение target metric не исправит сборку. Аналогично наличие VapourSynth ещё не гарантирует наличие конкретного plugin. Ошибки вида filter not found, missing plugin или невозможность рассчитать probe следует рассматривать как проблему зависимостей метрики, а не как сбой scene detection.

Метрики имеют разные шкалы и поведение, поэтому числовая цель одной метрики не переносится на другую. Не следует брать число VMAF и использовать его как target для SSIMULACRA2. Для практической настройки лучше выбрать одну метрику, подобрать значение на небольшом наборе сцен, визуально проверить результат и затем закрепить диапазон q и probe settings.

Пробные кодирования и разрешение метрики

--probe-res задаёт разрешение проб Target Quality, а --probing-rate определяет частоту отбора кадров. Базовый probing-rate равен 1. Снижение объёма данных ускоряет поиск, но делает оценку менее полной. --probes управляет числом пробных точек, --probing-speed может менять скорость пробного кодирования, а --probe-slow позволяет использовать более медленный режим, если требуется точнее приблизить поведение финального энкода.

Для VMAF есть собственное --vmaf-res; документация указывает базовое 1920x1080. Если исходник имеет другое разрешение, не нужно автоматически считать базовое значение оптимальным. Ключевой принцип — сравниваемые кадры должны проходить согласованную геометрическую обработку. При crop одинаковая обрезка должна учитываться и в кодировании, и в фильтре метрики.

Открытые отчёты об ошибках показывают, что сочетания probe settings, input resolution и итогового VMAF иногда требуют дополнительной проверки. Поэтому для важного архива разумно после завершения Target Quality отдельно измерить качество готового файла и сравнить его с ожидаемым, а не считать probe score абсолютной гарантией. av1an предоставляет отдельный режим VMAF после кодирования именно для такой проверки.

VMAF-график после кодирования

Флаг --vmaf запускает расчёт VMAF после завершения кодирования и сохраняет SVG-график рядом с выходным видео. Эта функция независима от Target Quality: можно закодировать ролик обычным режимом и затем получить распределение метрики по кадрам. График полезен тем, что показывает не только среднее число, но и провалы на отдельных сценах.

--vmaf-path позволяет указать путь к модели, --vmaf-res — разрешение расчёта, --vmaf-threads — число потоков, а параметр фильтра нужен для согласования геометрии, если кодирование использует crop или другое преобразование. Если после включения VMAF процесс падает ещё до подсчёта, первым делом следует проверить FFmpeg build и доступность libvmaf.

Метрика не заменяет визуальный просмотр. Высокий средний VMAF может скрывать короткие проблемные сцены, а особенности зерна или текстур иногда воспринимаются человеком иначе, чем агрегированная оценка. Практичный workflow — использовать график для поиска слабых участков, затем просмотреть именно эти сцены и при необходимости применить zones или изменить диапазон Target Quality.

Photon noise и синтез зерна

--photon-noise генерирует таблицу фотонного шума и применяет её через grain synthesis. Значение допускается от 0 до 64; документация сопоставляет 1 с ISO 100, а 64 с ISO 6400. Поддержка ограничена aomenc, rav1e и SvtAv1EncApp. Параметр полезен, когда хочется кодировать зернистый материал эффективнее, сохраняя воспринимаемую текстуру через синтез, а не тратить битрейт на буквальное воспроизведение каждого шумового пикселя.

Важно не включать одновременно photon-noise av1an и внутренний grain synthesis самого кодировщика. Документация предупреждает, что эти механизмы не следует комбинировать; av1an при своём режиме может отключить или перезаписать внутренний вариант encoder. --chroma-noise добавляет цветовую составляющую к таблице зерна.

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

Zones: разные настройки для разных участков

Файл zones позволяет задать участки видео с отличающимися параметрами. Каждая строка содержит start_frame, end_frame, encoder, необязательное слово reset и затем video params. Начальный кадр включается, конечный исключается. Границы зон становятся сценами, но дополнительный scene detection внутри зоны продолжает работать.

Без reset параметры зоны дополняют или переопределяют общие настройки. С reset av1an игнорирует относящиеся к encoder общие настройки и использует только заданные в зоне. Кроме аргументов конкретного кодировщика, в зоне разрешены некоторые опции av1an: extra split, min scene length, passes и настройки photon noise. Это делает zones удобным инструментом для отдельных очень сложных эпизодов или для смены энкодера на части ролика.

Зоны требуют точной работы с номерами кадров. Ошибка на единицу может затронуть соседнюю сцену, поэтому файл лучше строить из проверенного scene JSON или другого надёжного анализа. Zones не предназначены для вырезания кадров: они меняют способ кодирования заданного диапазона. Если нужно удалить заставку или рекламный блок, это следует сделать фильтром/монтажом до или во время подачи кадров.

Resume, временная папка и сохранение прогресса

--resume продолжает предыдущую сессию из временной директории. Для этого промежуточные данные должны сохраниться, поэтому --keep запрещает удалять temp после успешной работы и важен для сценариев, где планируется возобновление или диагностика. Имя временной папки без явного --temp формируется из хэша имени входного файла, а пользователь может задать собственный путь.

Возобновление особенно полезно для многочасовых AV1-задач: уже готовые чанки не требуется кодировать заново. При этом не стоит воспринимать resume как замену резервному копированию. Если temp очищен, перемещён или частично повреждён, восстановление может стать невозможным. Для длинной очереди разумно размещать временные данные на диске с достаточным запасом и не запускать автоматическую очистку до проверки финального файла.

--force отключает проверку валидности аргументов encoder, поэтому его стоит использовать только когда пользователь понимает, почему проверка мешает. --max-tries задаёт максимальное число повторных запусков проблемного чанка; базовое значение — 3. Если один и тот же chunk падает повторно, увеличение retries редко лечит первопричину: лучше изучить stderr, диапазон кадров и входной поток.

Логи, quiet и verbose

По умолчанию av1an пишет лог в каталог logs с именем, включающим дату. --log-file принимает относительный путь внутри этого каталога. Это удобно для долгих запусков: терминальное окно можно закрыть из поля внимания, а диагностические данные остаются в файле. Для автоматизации полезно давать логам имена, связанные с входным файлом или задачей.

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

Уровень логирования можно настроить отдельно. Важный принцип диагностики — сохранять команду, лог и версию внешнего encoder вместе. Ошибка может зависеть от конкретного SvtAv1EncApp, FFmpeg или VapourSynth plugin, и одного сообщения av1an недостаточно для воспроизведения. Если задача выполняется на нескольких машинах, одинаковые строки параметров ещё не гарантируют одинаковое окружение.

Proxy input для тяжёлых скриптов

Прокси-вход задаётся отдельно от основного input и используется для scene detection и Target Quality. Это не низкокачественный финальный encode и не источник, который попадает в результат. Его роль — дешёво предоставить алгоритмам кадры для анализа, пока фактический encoder позднее получает исходный поток или VapourSynth-скрипт.

Критическое условие — одинаковое число кадров. Прокси нельзя свободно менять по частоте кадров, удалять дубли или обрезать начало, если эти изменения не повторены в основном источнике. Иначе номера сцен перестанут соответствовать кадрам. Разрешение и качество прокси можно уменьшать только настолько, насколько это сохраняет надёжность scene detection и метрики.

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

Cache index рядом с источником или в temp

--cache-mode управляет местом хранения индексного файла source method. Значение source размещает индекс рядом с исходником и является базовым, temp переносит его во временную директорию. На read-only хранилище или сетевой папке без прав записи вариант source может вызвать ошибку, поэтому temp становится практической альтернативой.

Размещение индекса рядом с исходником полезно, если один и тот же файл кодируется несколько раз: некоторые source plugins могут повторно использовать подготовленные данные. В temp удобнее поддерживать чистоту медиатеки и удалять служебные файлы вместе с задачей. Выбор зависит от политики хранения, скорости диска и прав доступа.

Если av1an сообщает невозможность создать chunk/output или index, следует проверить свободное место, разрешения и длину пути. Для Windows также полезно исключить конфликт с защищёнными каталогами. Ошибка файловой системы не устраняется изменением CRF или workers; сначала нужно обеспечить возможность создавать временные и итоговые файлы.

Установка и зависимости в Windows

Для Windows проект предоставляет предсобранный av1an.exe, однако основная функциональность всё равно зависит от внешних компонентов. В документации перечислены FFmpeg, VapourSynth и как минимум один поддерживаемый encoder; дополнительные возможности требуют L-SMASH-Works, FFMS2, BestSource, DGDecNV, mkvmerge и библиотек метрик. Поэтому один exe не следует считать готовым комплектом кодеков для любых задач.

Самый надёжный первый тест — открыть PowerShell или cmd в каталоге, где доступны av1an и зависимости, проверить --version, а затем выполнить простое кодирование без Target Quality и сложных фильтров. Если encoder не найден, нужно исправить PATH или расположение executable. Если падает VapourSynth, проверить его установку и plugin loading. Только после базового запуска имеет смысл добавлять метрики и нестандартные chunk methods.

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

Linux и macOS: что учитывать

Проект поддерживает Linux, Windows и macOS. В Arch Linux и Manjaro av1an доступен через pacman, а универсальный путь для Rust-среды — cargo install av1an. Независимо от способа установки, внешние encoder binaries и мультимедийные зависимости остаются частью рабочего окружения. Docker-образ также существует и удобен для изолированного набора зависимостей.

На Linux thread affinity поддерживается, поэтому можно экспериментировать с закреплением workers за наборами потоков. На macOS этот параметр не работает. Для Apple Silicon следует особенно внимательно проверять архитектуру VapourSynth, FFmpeg и плагинов: открытые отчёты показывали случаи успешной сборки av1an с последующим segfault из-за окружения VSScript/архитектурных зависимостей.

Контейнеризация снижает число конфликтов зависимостей, но не меняет фундаментальную модель работы. Вход и выход нужно смонтировать в контейнер, а ресурсы CPU/памяти — выделить так, чтобы несколько workers не конкурировали с лимитами Docker. Для диагностики полезно сначала повторить проблему минимальной командой в том же окружении, где она возникает.

Кавычки и параметры в PowerShell и cmd

Одна из типичных проблем Windows связана не с кодированием, а с разбором аргументов. В issue проекта зафиксирован пример, когда вариант --ffmpeg, корректно выглядящий по документации, приводил к сообщению expected one argument из-за кавычек в PowerShell или cmd. Причина в том, что FFmpeg-строка сама содержит дефисы, двоеточия и иногда кавычки, а оболочка должна передать её av1an как одно значение.

Практический метод — начать с команды без -f, затем добавить простой фильтр без вложенных кавычек, убедиться, что он дошёл до FFmpeg, и только потом усложнять. Если используются пути с пробелами, их нужно экранировать отдельно от содержимого video-params. Перенос команды между Bash, PowerShell и cmd без адаптации кавычек ненадёжен.

Для повторяемой Windows-работы длинную команду лучше хранить в .ps1 или .bat с проверенным синтаксисом. Это уменьшает риск случайно потерять символ при копировании из браузера или мессенджера. В логах стоит сохранять итоговую строку и stderr: по ним видно, дошёл ли параметр до av1an и какой именно executable его отклонил.

Ошибка Encoder not found

Если av1an сообщает, что не найден encoder, проблема обычно означает отсутствие нужного executable в PATH или каталоге запуска. Для значения svt-av1 нужен SvtAv1EncApp, для aom — aomenc, для rav1e — rav1e, для vpx — vpxenc, для H.264 и HEVC — x264 и x265. Установка только библиотеки кодека без командного бинарника не удовлетворяет требованиям.

Перед изменением настроек av1an полезно вызвать сам encoder из той же консоли. Если оболочка не находит его по имени, av1an тоже не сможет запустить процесс. Если executable запускается, но версия не поддерживает переданные параметры, ошибка появится уже в stderr кодировщика; тогда следует сверить video-params с его собственной справкой.

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

VapourSynth и Failed to get VSScript API

Сбой VSScript означает, что av1an не смог получить API VapourSynth в текущем окружении. Один из воспроизводимых отчётов показывает запуск --version, который работал до активации Python venv и падал после неё. Это хороший пример того, как переменные окружения и выбранная Python-среда меняют загрузку нативных библиотек даже без изменения команды av1an.

Для диагностики нужно сравнить окружение до и после активации venv, проверить архитектуру Python/VapourSynth и убедиться, что требуемые библиотеки доступны загрузчику. Если задача не использует VapourSynth-скрипт, всё равно некоторые сборки av1an могут связываться с соответствующими компонентами, поэтому конфликт библиотеки способен проявиться при старте.

Не стоит одновременно менять Python, FFmpeg, плагины и encoder: это усложняет поиск. Сначала добиться стабильного av1an --version, затем проверить простой input, после — выбранный chunk method. Такой порядок быстро показывает, на каком уровне ломается цепочка.

Падение энкодера на отдельном чанке

Сообщение encoder crashed относится к внешнему процессу, который кодировал конкретный chunk. av1an выводит номер чанка и stderr, поэтому именно этот фрагмент можно исследовать отдельно. Причины варьируются от неподдерживаемой комбинации параметров и ошибок encoder binary до проблем с входными кадрами. Автоматический retry полезен при редком временном сбое, но постоянный SIGABRT на одном диапазоне требует анализа.

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

--max-tries не следует превращать в большое число в надежде, что постоянная ошибка исчезнет. Повторный запуск одного и того же детерминированного энкодера обычно приводит к тому же результату. Лучше исправить зависимость, параметры или проблемный источник и затем продолжить через resume.

Несовпадение числа кадров

av1an сравнивает ожидаемое количество кадров сцены с тем, что получил encoder. --ignore-frame-mismatch позволяет игнорировать обнаруженное различие, но это аварийный инструмент, а не обычная настройка. Несовпадение может указывать на VFR, повреждённый поток, особенности source plugin, фильтр, который добавляет/удаляет кадры, или ошибочную работу прокси.

Перед использованием ignore-frame-mismatch нужно понять, где появились лишние или потерянные кадры. Для материала с критичной синхронизацией аудио простое игнорирование риска особенно опасно: итоговый файл может постепенно уйти по времени. Полезно сравнить frame count через ffprobe/источник, сменить chunk method и проверить проблемный диапазон.

Если mismatch появляется только с одним VapourSynth-скриптом, проверить фильтры, меняющие fps или длину клипа. Если только на повреждённом файле — lsmash может намеренно остановиться там, где плеер скрывает битстримовую ошибку. В таком случае предварительное исправление/ремукс исходника бывает надёжнее принудительного продолжения.

Как выбирать число workers на практике

Для настройки производительности лучше использовать не абстрактный benchmark, а короткий фрагмент того же разрешения и с теми же фильтрами. Сначала оставить workers=0 и записать скорость, загрузку CPU, память и температуру. Затем попробовать несколько фиксированных значений, не меняя encoder preset. Цель — минимальное время при устойчивой работе, а не 100% CPU любой ценой.

Если каждый worker запускает encoder с большим внутренним числом потоков, рост workers быстро перестаёт помогать. На системах с несколькими CCD/NUMA-доменами thread affinity может дать более предсказуемую локальность, но требует эксперимента. Для 4K и сложных фильтров память или скорость декодирования способны стать лимитом раньше процессора.

Отдельно нужно учитывать Target Quality: probes добавляют короткие дополнительные encode, а затем финальные чанки. Оптимальное число workers для обычного прогона не всегда идеально для TQ. Если система начинает свопить, качество не улучшается — лишь растёт время и риск падения. Стабильная конфигурация предпочтительнее предельной.

Диск, временные файлы и скорость хранения

Методы hybrid и segment создают промежуточные файлы, поэтому свободное место может стать реальным ограничением. Даже при маленьком итоговом AV1-файле временные сегменты могут быть значительно крупнее. Если исходник находится на медленном HDD или сети, несколько workers одновременно читают разные части и создают конкурирующий I/O, что уменьшает пользу параллелизма.

VapourSynth-методы без intermediates снижают требования к временной ёмкости, но всё равно создают индексы и служебные данные. Temp лучше размещать на быстром диске с запасом, особенно при 4K/10-bit. После успешной проверки результата временную папку можно удалить, если resume больше не нужен.

При ошибке no space left или невозможности создать output chunk следует сначала освободить место и проверить права. Не стоит сразу менять bitrate: проблема может находиться в промежуточном lossless/segment этапе, размер которого слабо связан с финальным битрейтом. Для пакетной очереди полезно оценивать максимальный одновременный объём, а не размер одного результата.

Выходные контейнеры и дорожки

Matroska — наиболее естественный итоговый контейнер для av1an, когда используется mkvmerge. Он поддерживает несколько аудиодорожек и субтитры, которые av1an копирует или кодирует через FFmpeg. WebM возможен через FFmpeg concatenation при соответствующем выходном расширении и совместимых потоках. IVF предназначен для голого VP8/VP9/AV1-видео без аудио.

Контейнер не следует путать с кодеком. Расширение .mkv не означает AV1: внутри может быть x264, x265, VP9 или AV1 в зависимости от --encoder. Аналогично WebM накладывает ограничения на допустимые codec combinations. Если muxer сообщает несовместимый поток, менять нужно либо контейнер, либо codec/audio settings.

После сборки важно проверить не только запуск, но и перемотку, длительность, количество дорожек, субтитры и синхронизацию. Это особенно относится к FFmpeg concat из-за отмеченных проблем с audio seeking. Для автоматического архива можно добавить ffprobe-проверку после av1an и не удалять temp до её успешного завершения.

Пакетная обработка без встроенного GUI

av1an принимает один вход в типовой команде, а серию файлов удобно обрабатывать внешним циклом оболочки. В Bash, PowerShell или планировщике можно перечислить исходники, сформировать уникальный output и log для каждого, а затем вызывать av1an последовательно. Параллелить несколько полных av1an-задач поверх внутренних workers обычно невыгодно: они начинают конкурировать за те же CPU и память.

Для очереди стоит отделять параметры, общие для всех файлов, от переменных путей. Если коллекция содержит разные разрешения, frame rate и шум, один и тот же target/encoder preset не обязательно оптимален. Можно сначала классифицировать исходники, затем применить несколько профилей скрипта. Такой подход остаётся прозрачным: каждый запуск виден как обычная командная строка.

Встроенного визуального менеджера заданий, drag-and-drop списка и карточек устройств у av1an нет. Если нужен такой рабочий процесс, удобнее использовать GUI-фронтенд или другой конвертер. Сильная сторона av1an — сценарии, где параметры уже известны и важна воспроизводимая автоматизация.

Чего в av1an нет

У программы нет монтажного таймлайна, многодорожечной композиции, окна предпросмотра эффектов, титровального редактора, инструментов стабилизации и ручной цветокоррекции. Она не записывает экран, веб-камеру или поток и не занимается прямой трансляцией. Также av1an не авторит DVD/Blu-ray и не предназначен для захвата дисков. Эти задачи требуют отдельных приложений.

Нет и встроенного аппаратного encoder-переключателя NVENC, QSV или AMF в списке --encoder. DGDecNV относится только к декодированию чанков на NVIDIA. Если цель — максимально быстро кодировать на GPU, лучше использовать инструмент, который непосредственно поддерживает нужный аппаратный encoder, либо FFmpeg с соответствующим backend.

Плагины VapourSynth расширяют способы получения кадров и метрики, но это не plugin system с графическими эффектами внутри av1an. Пользователь строит обработку во внешнем VapourSynth-скрипте или FFmpeg-фильтре. Такой раздел ответственности делает CLI гибким, но требует понимания нескольких утилит сразу.

Сценарий: AV1 для большой коллекции

Для массового AV1-кодирования логично начать с SvtAv1EncApp как базового encoder, убедиться, что простой файл кодируется с минимальными параметрами, затем подобрать preset/quality на нескольких типичных сценах. После этого оставить scene detection standard, проверить автоматическое workers и оценить, нужен ли Target Quality. Если коллекция неоднородная, TQ может выровнять качество между простыми и сложными участками лучше единого CRF.

Аудио имеет смысл копировать, если исходный codec и контейнер подходят конечному использованию. Это исключает лишний lossy-проход. Для Matroska выбрать mkvmerge, если он установлен. На первых нескольких файлах сохранить temp и VMAF-график, чтобы убедиться, что настройки не дают провалов.

Когда схема проверена, её можно перенести в пакетный скрипт. Лог каждого файла сохранять отдельно, а после завершения автоматически проверять codec, duration, frame count и дорожки. Такой процесс даёт больше контроля, чем ручное запускание каждой команды, при этом не требует приписывать av1an функции полноценного медиаменеджера.

Сценарий: H.264 или HEVC с параллельными сценами

av1an не ограничен AV1: x264 и x265 доступны как encoder values. Это может быть полезно на машине с большим количеством ядер, если конкретный preset одного процесса не использует ресурсы так эффективно, как несколько независимых сцен. При этом нужно учитывать, что x264/x265 сами хорошо многопоточны, и дополнительный выигрыш от av1an может быть меньше, чем у некоторых AV1-настроек.

Для H.264/HEVC сохраняются те же принципы scene detection, chunk order, audio params и concat. Video params должны соответствовать standalone x264/x265, а не libx264/libx265 синтаксису FFmpeg. Перед длительным запуском проверить, что boundaries не нарушают ожидания по GOP и что финальный mux корректно воспроизводится.

Если задача — простая перекодировка одного файла на обычном CPU без Target Quality и без проблем загрузки ядер, прямой ffmpeg или HandBrake может быть проще. av1an имеет смысл, когда нужна именно его оркестрация, resume по чанкам, zones или per-scene quality workflow.

Сценарий: VP9 и WebM

VP9 кодируется через vpxenc при encoder vpx. Для вывода WebM нужен concat через FFmpeg, поскольку mkvmerge в описанном режиме ориентирован на Matroska. Двухпроходная схема для vpx используется по умолчанию вне RT, что нужно учитывать при оценке времени: каждый chunk может потребовать больше работы, чем один видимый проход.

Audio codec тоже должен быть совместим с WebM. Если исходная дорожка не подходит, её придётся перекодировать через --audio-params. Субтитры копируются базово, но совместимость конкретного типа subtitle с WebM лучше проверить отдельно. Ошибка mux обычно означает ограничение контейнера, а не scene detection.

Для VP9 Target Quality применим при корректно настроенном constant-quality режиме и поддерживаемой метрике. Перед масштабной очередью стоит проверить один короткий файл, потому что сочетание двух проходов, probes и нескольких workers способно заметно увеличить вычислительную нагрузку.

Сценарий: сложный VapourSynth-фильтр

Если исходная обработка описана в .vpy, можно подать скрипт напрямую. Для тяжёлого denoise или resize главной проблемой часто становится стоимость повторного вычисления кадров. В таком случае proxy input с тем же frame count способен ускорить scene detection и Target Quality. Финальный encoder при этом всё равно получает обработанные кадры основного скрипта.

Chunk method лучше выбирать среди VapourSynth-совместимых точных методов, проверяя доступность L-SMASH-Works, FFMS2 или BestSource. Если плагин не загружается, диагностику проводить вне av1an на простом vspipe-вызове. Это помогает отделить проблему скрипта от оркестратора.

При crop/resize в самом .vpy внимательно согласовать metric resolution и reference path. Target Quality должен сравнивать геометрически одинаковые кадры. Любое изменение длины клипа требует особенно осторожной работы с proxy и сценами, потому что их номера привязаны к frame mapping.

Как проверять готовый файл

Успешный exit code ещё не доказывает, что файл подходит задаче. Минимальная проверка включает открытие начала, середины и конца, перемотку, длительность, синхронизацию аудио, число дорожек и субтитры. Для кодирования с FFmpeg concat отдельно проверить seeking. Для Target Quality просмотреть сцены с минимальными значениями на VMAF-графике.

Техническую проверку можно автоматизировать через ffprobe: codec name, width/height, pixel format, frame rate, duration, stream count и container. Эти данные удобно сопоставить с исходником и ожидаемым профилем. Если frame count расходится, не удалять temp до выяснения.

Для архивной задачи полезно хранить команду и log рядом с результатом или в системе учёта. Это позволяет позже воспроизвести настройки и понять, почему два файла отличаются. av1an даёт детерминированную структуру параметров, но внешние encoder versions и plugins тоже влияют на результат, поэтому одного имени preset недостаточно.

Предварительный анализ через --sc-only

Режим --sc-only полезен, когда нужно отделить поиск сцен от многочасового кодирования. В этом режиме av1an выполняет анализ границ и завершает работу, не создавая финальное видео. Для практической настройки это позволяет сначала проверить, насколько разумно standard или fast делит конкретный материал, а уже затем запускать encoder. Особенно заметна польза на длинных роликах: ошибочно выбранная чувствительность или слишком короткие сцены обнаруживаются до того, как начнутся десятки дорогих encode-задач.

Результат анализа можно связать с файлом сцен. Если сцены подготовлены заранее, повторный запуск не обязан заново принимать те же решения. Это удобно при сравнении двух кодировщиков или нескольких наборов video-params: границы остаются одинаковыми, поэтому различия между результатами меньше зависят от самого этапа scene detection. При Target Quality фиксированные границы также упрощают сопоставление того, какие участки получили разные значения качества.

Перед применением готового списка нужно убедиться, что исходник не изменился по длине и порядку кадров. Нельзя безопасно переносить сцены на другую копию ролика, если после фильтрации удалялись или добавлялись кадры. Для proxy действует то же ограничение: документация требует одинакового frame count с основным input. Иначе номер кадра в аналитическом источнике перестаёт однозначно соответствовать номеру кадра в финальном энкоде.

Файл сцен и воспроизводимое разбиение

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

Практический подход для серии экспериментов состоит в том, чтобы один раз определить сцены, сохранить их и затем менять только encoder, video-params или Target Quality. Тогда каждая версия кодирует одинаковые временные участки, а итоговые логи легче сравнивать. Это особенно важно при разном числе workers: порядок завершения чанков меняется, но сами участки остаются прежними и финальная сборка сохраняет исходную последовательность.

Если после создания scenes выполняется crop или scale, границы по времени обычно остаются применимыми, потому что число кадров не меняется. Иная ситуация с фильтрами, изменяющими fps, дублирующими кадры или вырезающими диапазоны: сохранённая карта перестаёт соответствовать потоку. В таких случаях scene detection следует запускать уже на том представлении, которое имеет ту же кадровую структуру, что и фактический input для av1an.

Настройка масштаба для анализа и VMAF

Параметр --scaler используется av1an не для финального изменения разрешения видео, а для операций, где программе требуется масштабирование при поиске сцен или вычислении VMAF. По умолчанию применяется bicubic. Документация допускает масштабаторы FFmpeg, включая bilinear и варианты lanczos с заданной шириной. Поэтому --scaler не стоит путать с -f "-vf scale=...": первый влияет на служебный анализ, второй реально меняет кадры, передаваемые кодировщику.

При --sc-downscale-height уменьшение высоты ускоряет scene detection ценой меньшего количества деталей в анализируемом изображении. Здесь выбор scaler и высоты связан с компромиссом скорости и устойчивости детектора. Для материала с очевидными монтажными склейками можно начать с уменьшенного анализа и сравнить число найденных сцен с полноразмерным проходом. Если различия существенны, лучше уменьшить агрессивность downscale или отказаться от него для финальной карты.

В VMAF-разделе отдельно задаётся разрешение сравнения. Если финальное видео проходит crop, reference должен получать совместимое геометрическое преобразование, иначе метрика сравнивает несовпадающие изображения. Правильная последовательность — сначала определить фактический размер и область кадра после фильтра, затем согласовать metric resolution и reference filter, и только после этого интерпретировать числовые результаты.

Передача параметров в VSPipe

--vspipe-args нужен, когда VapourSynth-скрипт принимает внешние аргументы или av1an создаёт служебный loadscript для VapourSynth chunk method. Значения передаются как пары key=value. Это позволяет использовать один .vpy для нескольких вариантов обработки без копирования самого скрипта: например, значение blur, режим фильтра или другой параметр можно передать из команды запуска. Однако av1an не проверяет смысл таких ключей за скрипт — их должен понимать код VapourSynth.

Кавычки здесь критичны по той же причине, что и в --ffmpeg: оболочка должна передать каждую пару как одно значение. Аргумент, содержащий пробел, требуется оформить так, чтобы VSPipe получил его целиком. При проблеме лучше временно оставить один простой key=value и проверить, что скрипт видит значение, а затем добавлять остальные. Такой метод отделяет ошибку shell quoting от ошибки Python или конкретного плагина.

Опция применима только к VapourSynth-источникам и способам нарезки, которые используют VSPipe. Для чистого FFmpeg chunk method она ничего полезного не добавляет. Если скрипт зависит от нескольких параметров, имеет смысл записывать их вместе с командой и логом: иначе повторный запуск того же файла может дать иной кадр ещё до передачи в encoder, и сравнение настроек кодирования станет некорректным.

Безопасная перезапись выходных файлов

Для автоматических очередей важны два противоположных режима: -y разрешает перезаписать существующий output без вопроса, а -n запрещает перезапись без вопроса. Они нужны не для качества кодирования, а для предсказуемого поведения скрипта. В интерактивной консоли запрос можно заметить и решить вручную, но в планировщике или CI такой запрос способен остановить очередь, поэтому политику выходных файлов лучше выбрать заранее.

-n подходит для архива, где существующий результат нельзя случайно уничтожить. Скрипт может заметить код завершения, записать конфликт имени и перейти к следующему файлу. -y разумен только тогда, когда output является промежуточным или его имя гарантированно относится к текущей задаче. Автоматическая перезапись особенно рискованна при шаблонах имён: ошибка в переменной пути способна направить несколько заданий в один файл.

Эти флаги не заменяют проверку временной папки. Resume работает с сохранённым temp, а output может уже существовать после частично завершённой или предыдущей задачи. Поэтому при восстановлении сначала стоит сопоставить вход, temp и ожидаемый output, а затем выбирать overwrite policy. Такой порядок снижает риск продолжить один набор чанков и в конце заменить несвязанный готовый файл.

Когда нужен --force и почему с ним осторожнее

До начала кодирования av1an проверяет переданные через --video-params аргументы выбранного encoder. --force отключает эту проверку. Опция полезна, если бинарник поддерживает новый или нестандартный параметр, который валидатор av1an ещё не распознаёт, но она одновременно убирает раннюю защиту от опечаток. Поэтому применять --force как универсальный способ убрать ошибку проверки не стоит.

Перед принудительным запуском параметр нужно подтвердить непосредственно через --help используемого aomenc, SvtAv1EncApp, rav1e, vpxenc, x264 или x265. Если standalone encoder принимает строку, а av1an её отвергает, --force имеет понятную причину. Если сам encoder тоже сообщает неизвестную опцию, отключение проверки лишь перенесёт ошибку с подготовительного этапа на каждый chunk и создаст лишние перезапуски.

Особенно неприятна неверная строка в большой очереди: workers быстро получают одинаково некорректные задания, max-tries повторяет их, а лог разрастается одинаковыми сообщениями. Без --force такая проблема чаще обнаруживается до разделения на множество процессов. Поэтому нормальный режим — сохранить валидацию, а принудительный использовать только после точечной проверки совместимости конкретного encoder binary.

Pixel format и глубина цвета

--pix-format задаёт формат кадров, которые FFmpeg передаёт в кодирование. По умолчанию документация указывает yuv420p10le. Можно выбрать, например, yuv420p или yuv444p, если выбранный encoder, профиль и конечный проигрыватель это поддерживают. Это не косметический параметр: глубина и субсэмплинг влияют на совместимость и на то, какие данные реально получает кодировщик.

Нельзя считать десятибитный pipeline автоматическим повышением качества любого восьмибитного источника. Такой формат может быть полезен самому процессу кодирования и обработке градиентов, но он не восстанавливает отсутствовавшую точность исходника. В обратную сторону переход с 10-bit source на 8-bit требует осознанного преобразования, потому что часть уровней будет квантована. Для архивной задачи формат лучше выбирать по исходнику, возможностям encoder и требованиям воспроизведения.

Если encoder падает сразу после старта или сообщает неподдерживаемый input format, один из диагностических шагов — проверить --pix-format. Для yuv444p нужен соответствующий профиль кодека, а не каждый аппаратный или программный декодер одинаково хорошо воспроизводит 4:4:4. После смены pixel format обязательно проверить свойства финального потока через ffprobe, а не полагаться только на расширение файла.

Cache mode и повторное использование индексов

В encoding reference есть --cache-mode с базовым значением source. Этот параметр относится к кэшированию индекса, создаваемого source-плагинами при подготовке кадров. Индекс особенно заметен на больших файлах: первичный анализ может занять время, а повторное открытие того же источника без разумного кэша заставит лишний раз выполнять подготовительную работу. При сравнении методов важно учитывать и время индексации, а не только fps самого encoder.

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

При чистой диагностике полезно воспроизвести проблему на одном chunk с известным источником и затем сравнить lsmash, ffms2 или другой метод. Если ошибка следует за source method, а video-params не меняются, это сильный сигнал исследовать декодирование и индекс. Если одинаково падает каждый метод, вероятнее проблема самого потока, фильтра или encoder configuration.

Автоматический выбор tile count

--tile-auto оценивает количество tiles по разрешению и добавляет применимые параметры кодировщика. Это способ помочь encoder распараллелить работу внутри одного чанка, но он существует рядом с workers, а не вместо них. Workers определяет число одновременно кодируемых сцен, tiles — внутреннюю структуру конкретного encode, поэтому чрезмерное увеличение обоих уровней может вызвать конкуренцию за одни и те же потоки.

Практически tile-auto стоит сравнивать на реальном разрешении и preset. Для 1080p один баланс может быть удачным, для 4K — другой. Если encoder уже хорошо загружает CPU, дополнительные tiles не гарантируют ускорения. И наоборот, при большом числе workers агрессивная внутренняя многопоточность каждого экземпляра способна ухудшить суммарную производительность из-за переключений контекста и давления на память.

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

Probing: сколько проб и какой диапазон качества

Target Quality не знает нужный quantizer заранее, поэтому выполняет короткие probing-encode и по результатам метрики приближается к требуемому уровню. Число probes по умолчанию равно четырём. Увеличение количества проб может уточнить поиск, но прямо увеличивает работу до финального кодирования. На длинных очередях полезнее сначала проверить, что цель метрики вообще разумна, чем сразу максимизировать количество исследований каждого чанка.

Параметры минимального и максимального q ограничивают область, в которой алгоритм ищет качество. Допустимые фактические значения зависят от encoder, поэтому нельзя переносить одинаковые числовые границы между SvtAv1EncApp, aomenc и x264 без проверки их шкал. Слишком узкий диапазон приводит к тому, что часть сцен упирается в границу и не может приблизиться к target, даже если алгоритм поиска работает корректно.

Если несколько сцен систематически получают крайнее значение q, сначала нужно определить направление шкалы конкретного encoder и посмотреть фактическую metric value. Затем расширить только нужную границу и повторить небольшой тест. Слепое увеличение probes в этой ситуации не помогает: если требуемое значение находится вне разрешённого диапазона, дополнительные измерения лишь подтверждают тот же предел.

Probing rate, скорость и статистика

--probing-rate управляет долей кадров, используемых при пробах; документация допускает значения от 1 до 4 и использует 1 как базовое. Дополнительно probing speed задаёт быстрый encoder preset для аналитических проходов, а --probe-slow заставляет применять основные video-params вместо ускоренного режима. Эти настройки объясняют, почему Target Quality может оценивать сцену значительно быстрее финального encode и при этом требовать отдельной проверки точности.

Для сведения кадров одной probe в число используется probing-stat. Доступны mean, median, harmonic mean, root mean square, percentile, standard deviation, mode, min, max и автоматический выбор. Разные статистики отвечают на разные вопросы: среднее характеризует общий уровень, а нижний percentile или minimum сильнее реагируют на худшие кадры. Поэтому target нельзя оценивать отдельно от способа агрегации — одинаковое число при разных statistics может означать разную практическую строгость.

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

Разрешение probing и стоимость метрик

--probing-res позволяет выполнять Target Quality probing не обязательно в полном исходном разрешении. Это важный рычаг скорости на 4K и более тяжёлых источниках: уменьшенное изображение быстрее кодировать и сравнивать. Однако оно одновременно меняет характер деталей, поэтому результат поиска является приближением к поведению полного кадра. Чем сильнее downscale, тем осторожнее нужно переносить найденный q на финальный encode.

Разные метрики имеют разные зависимости. VMAF опирается на libvmaf/FFmpeg-компоненты, SSIMULACRA2 и Butteraugli требуют своих доступных инструментов, XPSNR — соответствующей реализации. Если av1an сообщает, что metric backend отсутствует, смена encoder или workers не исправит проблему. Сначала нужно подтвердить саму metric dependency в том же окружении, где работает av1an.

При пакетной работе полезно отделить два вопроса: достаточно ли быстро выполняется probing и соответствует ли найденное качество ожиданию на полном размере. Ускорение аналитики имеет смысл только после проверки второго. Один короткий тест с исходным probe resolution даёт контрольную точку, с которой затем можно сравнить уменьшенный вариант по выбранному q и финальной метрике.

Zones для разных участков одного ролика

Файл zones задаёт диапазоны кадров с отличающимися encoder settings. Каждая строка содержит start frame, end frame, encoder, необязательный reset и затем video params. Начальная граница включается, конечная не включается; значение -1 может обозначать конец ролика. Обе границы становятся scene cuts, но внутри зоны автоматический scene detection продолжает работать, поэтому зона не превращается в один гигантский chunk.

Практический сценарий — участок с другим типом материала, для которого нужен отдельный encoder preset или параметр качества. Вместо запуска двух независимых команд и ручной склейки можно описать диапазоны одной задачей. Reset позволяет контролировать, наследуются ли настройки между зонами. Поскольку параметры идут непосредственно encoder binary, синтаксис в zones должен соответствовать выбранному encoder так же строго, как строка --video-params.

Границы зон лучше получать из точного frame numbering, а не оценивать по времени на глаз, особенно при нестандартном frame rate. Перед большой задачей полезно сделать короткий тест, в котором начало и конец каждой зоны легко найти, и проверить лог: там должно быть видно, что нужные чанки получили нужный набор параметров. Ошибка на один кадр меняет, какой segment относится к какой политике кодирования.

Как читать прогресс и оценку оставшегося объёма

Обычный вывод терминала показывает ход обработки чанков и сводные показатели, а --verbose добавляет дополнительную статистику. Поскольку сцены имеют разную длину и сложность, процент готовых чанков сам по себе не равен проценту готового времени. Именно поэтому long-to-short ставит самые длинные задания раньше: к концу очереди меньше вероятность, что все workers простаивают, ожидая единственную тяжёлую сцену.

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

Если скорость резко падает только ближе к конкретному диапазону, это не обязательно деградация системы: одна сцена может быть значительно сложнее или длиннее. Для диагностики сравнить номер чанка, encoder stderr и загрузку ресурсов. При устойчивом падении всей очереди со временем проверить thermal throttling, память и I/O, но не менять порядок чанков как средство исправления аппаратной проблемы.

Логи: quiet, verbose и уровни подробности

-q отключает печать прогресса в терминал, что удобно для автоматических задач, где вывод собирает внешний планировщик. --verbose, наоборот, добавляет данные о ходе работы и статистику. Файл лога задаётся отдельно через --log-file; документация требует относительный путь внутри каталога logs. Если имя не задано, av1an формирует датированный log. Это важно учитывать при скриптах, которые после запуска ищут конкретный файл.

--log-level влияет именно на файловый лог и допускает error, warn, info, debug и trace. Базовым уровнем указан debug. Trace создаёт особенно подробный поток и, среди прочего, включает решения scenechange для rav1e. Такой уровень полезен при воспроизводимой ошибке, но для постоянной большой очереди способен создавать ненужный объём, поэтому его разумно включать только на проблемном файле.

Хорошая диагностическая запись содержит команду, environment information, log и stderr encoder. Одной фразы encoder crashed недостаточно, если затем изменились PATH или версии внешних компонентов. Для повторения ошибки сначала вернуть ту же команду и минимальный input; если она воспроизводится, уже после этого сравнивать другой chunk method или encoder binary.

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

Программа	Лучше подходит для	Главное ограничение
av1an	Параллельного кодирования по сценам и Target Quality	Нет графического интерфейса, требуются внешние компоненты
FFmpeg	Универсального транскодирования, фильтров и автоматизации	Сам не строит av1an-подобную очередь независимых сцен
ab-av1	Автоматического поиска CRF по метрике для AV1 через FFmpeg	Не является многокодековым оркестратором чанков
NotEnoughAV1Encodes	AV1-кодирования с графическим управлением и разбиением	Фокусируется прежде всего на AV1 и GUI-сценарии
FastFlix	Графической настройки FFmpeg-кодировщиков и очереди	Не даёт тот же per-scene Target Quality workflow
HandBrake	Простой пакетной перекодировки с готовыми пресетами	Нет av1an-подобного управления сценовыми чанками

Если главная цель — вручную выбрать формат и получить файл без глубокого погружения в CLI, HandBrake или FastFlix проще. FFmpeg лучше там, где нужен максимально широкий набор фильтров, контейнеров и аппаратных кодировщиков. ab-av1 близок по идее автоматического поиска качества, но решает более узкую задачу. av1an выделяется сочетанием scene-based parallelism, нескольких standalone encoders, resume, zones и Target Quality по нескольким метрикам.

Выбор стоит делать по bottleneck. Если один AV1 encoder плохо загружает многоядерный CPU, av1an способен эффективно распределить сцены. Если ограничение — GPU encoder или визуальный монтаж, его преимущества почти не используются. Для домашней разовой конвертации CLI-сложность может быть избыточной, а для повторяемого энкодинг-пайплайна она превращается в плюс, потому что все параметры можно зафиксировать в скрипте.

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

Можно ли просто перетащить файл в окно?

Штатного drag-and-drop GUI нет. Вход передаётся через -i в командной строке. При желании пользователь может написать оболочку или использовать сторонний фронтенд, но это уже отдельный продукт.

Есть ли встроенный AV1-кодировщик?

Нет. av1an запускает aomenc, SvtAv1EncApp или rav1e. Для VP9 нужен vpxenc, для H.264 — x264, для HEVC — x265.

Можно ли сохранить исходный звук?

Да. Без --audio-params базовое поведение — -c:a copy. Субтитры также копируются по умолчанию.

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

Да, через FFmpeg crop в --ffmpeg. Это текстовая фильтрация, а не визуальный crop tool. При Target Quality такой же геометрический фильтр нужно учесть в метрике.

Работает ли GPU-кодирование?

В штатном списке encoder нет NVENC, QSV или AMF. DGDecNV использует NVIDIA для декодирования поддерживаемых входных кодеков, но это не финальный GPU encoder.

Что выбрать для chunk method?

Если доступен L-SMASH-Works, lsmash обычно хороший старт. ffms2 — точная альтернатива, BestSource — медленный, но особенно точный вариант. Без VapourSynth можно использовать hybrid; select точный, но очень медленный, segment зависит от исходных keyframes.

Зачем нужен random chunk order?

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

Когда использовать resume?

После прерванного длительного кодирования, если временная папка сохранена. Для этого удобно заранее использовать --keep и понятный --temp.

Почему Target Quality работает медленнее?

До финального кодирования выполняются probes и расчёт метрик. Это дополнительная работа, предназначенная для выбора качества по сегментам.

Можно ли отключить поиск сцен?

Да, split-method none отключает автоматический scene detection. Дополнительные разрезы можно оставить через extra-split.

Какая главная проверка перед большой очередью?

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

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

1. Проверить, что av1an запускается и показывает сведения о сборке без ошибки.
2. Проверить доступность выбранного encoder binary из той же консоли.
3. Убедиться, что FFmpeg и при необходимости VapourSynth видны в окружении.
4. Выбрать chunk method и проверить его на коротком фрагменте.
5. Оценить свободное место для temp и промежуточных файлов.
6. Начать с workers=0, затем сравнить несколько значений на реальном материале.
7. Отдельно проверить video-params у самого кодировщика.
8. Если используется crop/scale и метрика, согласовать геометрию reference и encode.
9. Для Target Quality проверить наличие конкретной metric dependency.
10. Для важной задачи сохранить temp, log и команду до проверки финального файла.

После старта обратить внимание на найденное число сцен, количество workers, выбранный chunk method и сообщения внешнего encoder. Слишком раннее падение обычно связано с зависимостями или аргументами; повторяющийся сбой на конкретном chunk — с источником, source method или encoder. Если прогресс идёт, но скорость ниже ожидаемой, измерять CPU, RAM и I/O, а не менять сразу несколько параметров.

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