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

Основной исполняемый файл принимает несжатое видео YUV4MPEG2 (Y4M) и записывает сжатый AV1 в контейнер IVF. Поэтому типичный рабочий процесс строится вокруг двух этапов: подходящий декодер или FFmpeg подготавливает поток Y4M, а rav1e выполняет собственно AV1-кодирование. Если нужен MP4 или Matroska со звуком и субтитрами, готовый видеопоток затем объединяют с остальными дорожками отдельным мультиплексором.

В rav1e сосредоточены параметры, которые действительно относятся к видеокодеку: квантование, целевой битрейт, скорость поиска, количество потоков и тайлов, структура ключевых кадров, lookahead, определение смен сцен, режимы качества, метаданные цвета, глубина 8/10/12 бит и форматы цветовой субдискретизации 4:2:0, 4:2:2 и 4:4:4. Это делает программу полезной для автоматизированных конвейеров, сравнительных тестов и тех случаев, где требуется напрямую контролировать программное кодирование AV1.

Для чего нужен rav1e

rav1e — программный кодировщик видео в AV1. Его задача не в монтаже, не в воспроизведении и не в конвертации любого файла в любой файл, а именно в преобразовании последовательности кадров YUV в AV1-битстрим. Такое разделение функций важно понимать до начала работы: если исходник находится в MP4, MKV, MOV, MPEG-TS или другом медиаконтейнере, сначала требуется декодировать видеодорожку и подать rav1e поток в формате Y4M. В результате отдельный этап декодирования не скрыт от пользователя и легко контролируется.

Программа поддерживает intra-, inter- и switch-кадры, использует суперблоки 64×64 и выбирает квадратные и прямоугольные блоки кодирования средствами RDO. На практике эти внутренние механизмы не требуют ручной разметки: пользователь задаёт целевые параметры, а кодировщик сам выбирает структуры предсказания и преобразования. При этом на уровне CLI остаются доступными наиболее важные рычаги: --quantizer, --bitrate, --speed, интервалы ключевых кадров, тайлы, режим низкой задержки и варианты настройки качества.

Главная особенность рабочего подхода rav1e — предсказуемость входа и выхода. Входной Y4M уже содержит ширину, высоту, частоту кадров и описание выборок, поэтому кодировщик не занимается анализом контейнеров, поиском нужной дорожки, декодированием H.264/HEVC или обработкой аудио. Выходной IVF, в свою очередь, удобен как промежуточный контейнер для AV1. Такое устройство особенно логично в сценариях, где подготовка кадров и окончательный mux уже выполняются другими инструментами.

• для постоянного качества используется квантование с диапазоном 0–255: меньшие значения означают более высокое качество и обычно больший поток данных;
• для заданного объёма или полосы пропускания используется целевой битрейт, в том числе в одно- и многопроходной схеме;
• для управления вычислительной сложностью предусмотрено 11 уровней скорости от 0 до 10;
• для загрузки нескольких ядер применяются потоки и разбиение кадра на тайлы;
• для потоковых сценариев есть режим низкой задержки, меняющий порядок кадров и компромисс между задержкой и эффективностью.

rav1e также можно использовать как библиотеку через Rust API или C-совместимый API. Отдельно существует интеграция librav1e в FFmpeg: в этом случае FFmpeg выполняет демультиплексирование, декодирование, фильтрацию и мультиплексирование, а библиотека rav1e отвечает за AV1. Это другой способ подключения того же кодировщика и не следует путать его с отдельной программой или сторонним графическим интерфейсом.

Как устроен рабочий процесс

Самый простой конвейер выглядит так: исходное видео превращается в Y4M, Y4M передаётся rav1e, а полученный IVF проверяется декодером или переносится в конечный контейнер. Если исходник уже подготовлен в Y4M, первый этап не нужен. Если требуется только исследование параметров кодировщика, удобно работать с короткой тестовой последовательностью, потому что результат можно быстро перекодировать несколько раз с разными значениями --speed, --quantizer или тайлов.

Базовая форма команды для подготовленного файла:

rav1e input.y4m -o output.ivf

Здесь input.y4m содержит несжатые кадры, а output.ivf становится AV1-видеопотоком в IVF. Если файл результата уже существует, rav1e может потребовать подтверждение перезаписи; в сценариях автоматизации обычно явно добавляют -y, чтобы не зависеть от интерактивного запроса.

Если исходник находится в обычном медиаконтейнере, практичнее не записывать огромный промежуточный Y4M на диск, а использовать конвейер. Например, FFmpeg может вывести Y4M в стандартный поток, а rav1e прочитает его через -:

ffmpeg -i input.mkv -pix_fmt yuv420p -f yuv4mpegpipe - | rav1e - -o output.ivf

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

Что остаётся за пределами кодировщика

rav1e не переносит аудиодорожку из исходника и не создаёт меню, главы или субтитры. Если нужен финальный MKV, типовой подход — сначала получить video.ivf, затем открыть его вместе с исходником в FFmpeg и скопировать AV1-видеопоток без повторного кодирования. Аудио при этом можно скопировать либо перекодировать независимо. Такая схема избавляет от двойного сжатия видео.

ffmpeg -i video.ivf -i source.mkv -map 0:v:0 -map 1:a? -map 1:s? -c:v copy -c:a copy -c:s copy final.mkv

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

Почему Y4M удобен для rav1e

YUV4MPEG2 — простой потоковый формат, который передаёт кадры вместе с основными параметрами видео. Для rav1e это означает, что ему не требуется собственный набор декодеров. Пользователь может подготовить Y4M практически из любого источника инструментом, умеющим его декодировать. Одновременно это ограничение: передать напрямую H.264-файл или MKV в rav1e нельзя.

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

Выбор сборки и подготовка запуска

Официальные релизы проекта публикуют готовые бинарные файлы для нескольких платформ и вариантов процессорных инструкций. На Windows встречаются отдельный rav1e.exe и архивы, собранные с разными toolchain. Для обычного пользователя важнее всего архитектура процессора и набор инструкций. Сборка, оптимизированная под AVX2, предназначена только для процессоров, где AVX2 действительно доступен; универсальный вариант безопаснее для переноса между разными компьютерами.

Принцип выбора прост: если неизвестно, какие расширения поддерживает целевая машина, берут generic-сборку. SSE4-вариант уместен на достаточно старых x86-64 системах, которые поддерживают SSE4, а AVX2 — на более новых CPU. Оптимизированный бинарник не превращает rav1e в аппаратный кодировщик: вычисления всё равно выполняются программно на центральном процессоре, но часть внутренних операций использует SIMD.

На Windows отдельный rav1e.exe можно хранить в рабочей папке и запускать по полному пути. Для постоянной работы удобнее добавить каталог в переменную PATH. Проверка после установки не должна сразу кодировать длинный ролик: сначала достаточно запросить версию и справку.

rav1e --version
rav1e --help

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

GNU, MSVC и переносимость

Windows-архивы могут быть собраны с GNU или MSVC toolchain. Для пользователя CLI различия обычно не меняют синтаксис команд, но важны при интеграции библиотек, отладке и совместимости с окружением. Если rav1e используется только как отдельный exe, рационально начать с generic-сборки и переходить к более специфичной только при понятной причине.

При собственноручной сборке проект использует Rust. Для x86-64 ассемблерные оптимизации требуют NASM; при штатной сборке они включаются по умолчанию. Наличие готовых бинарников позволяет избежать подготовки компилятора, но разработчикам библиотечных интеграций может понадобиться cargo build --release или построение C API через cargo-c.

Справка командной строки

У rav1e нет окон с вкладками и ползунками: все настройки задаются опциями. Поэтому --help — фактически основное меню программы. В справке параметры сгруппированы по назначению: вход/выход, потоки, скорость, rate control, ключевые кадры, цвет, метрики и дополнительные режимы. Список опций конкретной сборки важнее сторонней памятки, поскольку часть экспериментальных возможностей могла меняться.

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

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

Подготовка исходника через FFmpeg

FFmpeg в связке с rav1e чаще всего используется как декодер и фильтровальный фронтенд. Он читает контейнер, выбирает видеодорожку, при необходимости масштабирует кадр, переводит пиксельный формат и отправляет Y4M в stdout. rav1e получает уже готовые кадры. Если в исходнике требуется деинтерлейсинг, crop, scale или преобразование кадровой частоты, эти операции логично выполнить до кодировщика.

Для обычного SDR-видео распространён 8-битный yuv420p:

ffmpeg -i input.mp4 -pix_fmt yuv420p -f yuv4mpegpipe - | rav1e - -o output.ivf --speed 6 --quantizer 100

Для 10-битного материала выбирают соответствующий пиксельный формат, например yuv420p10le. Важно не делать принудительное преобразование в 8 бит только потому, что пример команды оказался короче: понижение глубины до запуска rav1e необратимо удалит часть градаций. Аналогично, превращение 4:4:4 в 4:2:0 — отдельное решение о цветовой субдискретизации, а не обязательное условие работы кодировщика.

Поток через стандартный ввод удобно обозначать одним дефисом. Если равным образом использовать дефис для вывода, следует учитывать, что служебные сообщения кодировщика должны оставаться отделены от бинарного потока; для обычной работы проще писать IVF в файл. В Windows PowerShell и классическом cmd.exe поведение конвейеров исторически различалось, поэтому при подозрении на проблему стоит проверить тот же процесс через промежуточный Y4M.

Масштабирование и частота кадров

rav1e не является масштабатором. Если нужно преобразовать 4K в 1080p, сделать letterbox или исправить sample aspect ratio, это задача этапа подготовки кадров. То же относится к принудительному изменению fps. Y4M сообщает частоту кадров кодировщику, и она влияет на временные параметры потока и расчёт битрейта. Ошибочная частота на входе приведёт к неправильной длительности независимо от качества сжатия.

При изменении fps следует решить, должны ли кадры дублироваться/удаляться или требуется интерполяция. Сам rav1e не подменяет такую обработку. В скрипте полезно отделять фильтр подготовки от параметров кодирования: тогда ясно, из-за какого этапа появились лишние кадры, изменение резкости или неожиданная длительность.

Проверка Y4M до долгого кодирования

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

Если тестовый фрагмент уже не запускается, нет смысла менять сразу пять параметров качества. Сначала возвращаются к минимальной команде, затем добавляют по одному: pixel format, quantizer, speed, tiles, HDR-метаданные. Такой порядок локализует ошибку гораздо быстрее, чем перебор случайных комбинаций.

Квантование: управление качеством через --quantizer

Режим постоянного квантователя — самый прямой способ задать степень сжатия. Параметр --quantizer принимает значения от 0 до 255. Чем меньше число, тем слабее квантование и тем больше деталей кодировщик старается сохранить; вместе с этим обычно растёт битрейт. Большие значения агрессивнее сокращают объём данных и быстрее выявляют артефакты на мелких текстурах, градиентах, дыме, зерне и сложном движении.

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

Пример явного режима качества:

rav1e input.y4m -o q90.ivf --quantizer 90 --speed 6

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

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

Минимальный квантователь в режиме битрейта

Параметр --min-quantizer относится к ограничению rate control: он задаёт нижнюю границу квантования там, где используется целевой битрейт. Это не замена --quantizer для постоянного качества. Если минимальный квантователь установлен слишком низко или слишком высоко относительно задачи, распределение битов может стать менее гибким. Значение имеет смысл задавать только при понятной цели, например когда нужно не позволять системе расходовать слишком много битов на отдельные лёгкие кадры.

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

Целевой битрейт и управление размером

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

Величина битрейта сама по себе не определяет качество без контекста разрешения, fps, содержания и длительности GOP. 1 Мбит/с для 720p-анимации и 1 Мбит/с для шумного 4K-видео — принципиально разные нагрузки. При подготовке пресета полезно рассматривать битрейт как бюджет, который распределяется между кадрами, а не как универсальную меру качества.

rav1e input.y4m -o target.ivf --bitrate 1800 --speed 6

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

Однопроходное кодирование

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

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

Двухпроходный режим

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

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

rav1e input.y4m --first-pass pass1.stat --bitrate 1800 --speed 6 -o first.ivf
rav1e input.y4m --second-pass pass1.stat --bitrate 1800 --speed 6 -o final.ivf -y

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

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

Reservoir frame delay

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

Вместо механического копирования значения из чужой команды стоит исходить из сценария. Для файлового кодирования задержка редко является главным ограничением, а для потоковой передачи она может быть критичной. Изменение reservoir нужно рассматривать вместе с low latency, структурой GOP и возможностями принимающей стороны.

Скорость кодирования: пресеты 0–10

rav1e предоставляет 11 уровней скорости. Нулевой уровень направляет больше вычислений на поиск эффективного представления кадра, десятый сокращает объём анализа и быстрее выдаёт результат. Это не качество 0–10: при одинаковом квантователе разные скорости меняют эффективность кодирования, то есть соотношение качества, размера и времени.

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

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

rav1e clip.y4m -o s4.ivf --speed 4 --quantizer 90
rav1e clip.y4m -o s6.ivf --speed 6 --quantizer 90
rav1e clip.y4m -o s8.ivf --speed 8 --quantizer 90

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

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

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

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

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

Потоки и загрузка многоядерного процессора

--threads ограничивает размер пула потоков. Значение 0 означает выбор на основе количества логических CPU. Однако само наличие десятков потоков не гарантирует линейного ускорения. Параллелизм зависит от разрешения кадра, структуры алгоритма и количества тайлов. На небольшом видео дополнительные потоки могут простаивать, потому что внутри одного кадра недостаточно независимой работы.

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

rav1e input.y4m -o tiled.ivf --threads 16 --tiles 4 --speed 6 --quantizer 90

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

Tile rows, tile cols и общее число тайлов

rav1e позволяет задавать число строк и столбцов тайлов либо общее число. Для отдельных параметров строки и столбцы должны соответствовать ограничениям программы; в справке указывается требование степеней двойки, а кодировщик может корректировать выбор с учётом разрешения. Параметр --tiles задаёт желаемое общее количество и может быть удобнее, если точная геометрия не важна.

Разбиение на 2×1 и 2×2 часто используют как отправную точку для высокого разрешения, но это не универсальный рецепт. На 1080p множество мелких тайлов способно дать меньше пользы, чем на 4K, потому что каждому тайлу достанется слишком маленькая область. На очень большом кадре, наоборот, один тайл ограничивает параллельность.

Лучший способ подобрать тайлы — провести серию одинаковых коротких прогонов: один тайл, два, четыре, затем сравнить fps, загрузку и размер файла. Если скорость перестала расти, дальнейшее дробление не нужно. Для финального профиля следует также сравнить качество или метрики, поскольку throughput — только одна сторона компромисса.

Параллельные задания вместо одного большого пула

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

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

Ключевые кадры и структура GOP

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

Максимальный интервал выбирают с учётом fps и целевого способа использования. Значение в кадрах удобнее переводить в секунды: при 24 fps интервал 240 кадров — около десяти секунд, при 60 fps те же 240 кадров — четыре секунды. Поэтому копирование одного keyint между источниками с разной частотой кадров меняет реальное поведение.

rav1e input.y4m -o gop.ivf --min-keyint 24 --keyint 240 --speed 6 --quantizer 90

Определение смен сцен может вставлять ключевые кадры в логичных точках, если они не нарушают заданные пределы. Минимальный интервал защищает от слишком близких ключевых кадров, а максимальный гарантирует, что расстояние не станет чрезмерным. Для HLS/DASH и другого сегментирования требования могут задаваться внешним упаковщиком; в таком случае структура GOP должна согласовываться с границами сегментов.

Switch frames

Switch frame — отдельный тип кадра AV1, предназначенный для сценариев переключения потоков и случайного доступа в определённых структурах. В rav1e есть параметр интервала switch frames. Если задача не связана с таким переключением, его не нужно включать только потому, что опция существует. Для обычного файла достаточно стандартной структуры intra/inter кадров.

Интервалы switch frames взаимодействуют с общей структурой GOP. Неправильно выбранные значения способны добавить накладные расходы, не дав полезного свойства. Перед использованием стоит проверить требования конечного потокового протокола или собственного декодера.

Определение смен сцен и lookahead

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

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

RDO lookahead задаёт объём будущих кадров, который кодировщик учитывает при принятии решений. Больший lookahead даёт больше контекста, но требует памяти и добавляет задержку. Это особенно важно, когда rav1e используется не для офлайн-файла, а в интерактивном или потоковом процессе.

Режим низкой задержки

--low-latency меняет порядок работы так, чтобы уменьшить необходимость ждать будущие кадры; в справке rav1e отмечается значимый компромисс скорости/качества. Такой режим имеет смысл там, где задержка важнее максимальной эффективности сжатия: интерактивная передача, удалённый экран, некоторые live-сценарии. Для архивного кодирования готового файла он обычно не даёт преимущества сам по себе.

Низкая задержка — не то же самое, что самый быстрый пресет. --speed управляет вычислительной сложностью, а low latency — временной структурой кодирования. Их можно сочетать, но они решают разные задачи. При настройке live-профиля следует отдельно измерять processing latency, throughput и визуальное качество.

Настройка качества: Psychovisual и Psnr

rav1e позволяет выбирать направление оптимизации через --tune. Вариант Psychovisual ориентирован на визуальное восприятие, а Psnr — на поведение, удобное для объективной метрики PSNR. Это не переключатель хорошо/плохо: режим выбирают по цели эксперимента.

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

Нельзя сравнивать два кодировщика только по одной метрике и автоматически переносить вывод на субъективное качество. Если нужны объективные оценки, полезно использовать несколько показателей и визуальную проверку. rav1e способен выводить PSNR и дополнительные метрики в соответствующих режимах, но их расчёт увеличивает работу и не нужен в обычном производственном кодировании.

Синтез плёночного зерна и photon noise

AV1 позволяет описывать синтетическое зерно отдельно от основного предсказанного изображения. Идея полезна для материалов, где мелкозернистая структура сильно нагружает кодировщик: вместо попытки буквально сохранить каждое случайное изменение пикселей можно закодировать более чистую базу и передать параметры восстановления зерна. В rav1e для этого предусмотрены параметры, связанные с film grain, а также --photon-noise.

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

rav1e также умеет работать с таблицей film grain, совместимой по формату с инструментами экосистемы AV1. Это полезно, если анализ зерна выполняется отдельным этапом и кодировщик должен применить уже рассчитанные параметры. В производственном конвейере такой файл следует хранить рядом с конкретным источником или идентификатором задания, чтобы таблица от одного ролика случайно не использовалась для другого.

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

Глубина цвета 8, 10 и 12 бит

rav1e поддерживает 8-, 10- и 12-битные данные. Глубина определяет количество уровней, доступных каждому компоненту, и напрямую влияет на точность градиентов и запас при обработке. Однако переход на 10 или 12 бит сам по себе не восстанавливает информацию, уже потерянную в 8-битном источнике. Если исходник изначально 8-битный, увеличение разрядности перед кодированием может быть полезно для отдельных фильтров, но не создаёт новых деталей.

При работе через FFmpeg выбор глубины фиксируется пиксельным форматом Y4M. Например, yuv420p10le формирует 10-битный 4:2:0 поток. Rav1e распознаёт параметры из заголовка Y4M. Поэтому наиболее распространённая ошибка — не в отдельном флаге rav1e, а в том, что FFmpeg раньше по цепочке преобразовал источник в другой формат.

ffmpeg -i source.mkv -pix_fmt yuv420p10le -f yuv4mpegpipe - | rav1e - -o video10.ivf --speed 6 --quantizer 90

Для HDR 10 бит обычно являются практическим минимумом, но полноценный HDR-процесс требует ещё корректных primaries, transfer characteristics, matrix coefficients, range и статических метаданных. Одна надпись 10le в пиксельном формате не означает, что цветовое описание автоматически соответствует HDR10.

Цветовая субдискретизация 4:2:0, 4:2:2 и 4:4:4

Субдискретизация описывает, с каким пространственным разрешением хранятся цветоразностные компоненты относительно яркости. 4:2:0 экономит много данных и широко используется в доставке видео; 4:2:2 сохраняет больше горизонтальной цветовой информации; 4:4:4 не уменьшает разрешение цветовых компонентов. rav1e способен работать с этими вариантами, но конечная совместимость зависит от контейнера, профиля AV1 и декодера.

Для обычного кино и веб-видео 4:2:0 часто является ожидаемым форматом. Для экранной графики с мелким цветным текстом, промежуточных мастер-файлов и некоторых профессиональных задач 4:4:4 может сохранять более точные цветные границы. Выбор нельзя сводить к правилу 4:4:4 всегда лучше: он увеличивает объём информации и может ухудшить совместимость с аппаратными декодерами.

Если исходник 4:2:0, преобразование в 4:4:4 перед rav1e не возвращает утраченные хрома-сэмплы. Поэтому решение следует принимать по исходному материалу и цели, а не по максимальному числу в настройке. Аналогично, если мастер 4:4:4 нужен для дальнейшей обработки, преждевременное преобразование в 4:2:0 уже нельзя полностью отменить.

Диапазон уровней: limited и full

Параметр range сообщает, какой числовой диапазон яркости и цвета предполагается в потоке. Limited и full — это не фильтры контрастности. Они описывают интерпретацию значений. Если данные фактически full range, но помечены limited, или наоборот, проигрыватель может показать поднятый чёрный, проваленные тени или неправильный контраст.

Важнейшее правило: метка должна соответствовать самим пиксельным значениям. Нельзя исправить неверно преобразованные уровни простым изменением metadata. Если FFmpeg действительно конвертирует диапазон, это отдельная операция; rav1e затем должен получить корректное описание результата. При подозрении на ошибку проверяют и фильтры, и metadata, а не только один параметр.

Color primaries, transfer и matrix coefficients

rav1e позволяет передать базовое цветовое описание потока: primaries, transfer characteristics и matrix coefficients. Эти три параметра отвечают на разные вопросы. Primaries описывают координаты основных цветов, transfer — связь кодового значения с яркостью, matrix — преобразование между RGB и YCbCr. Случайная комбинация может формально кодироваться, но неверно интерпретироваться дальше по цепочке.

Для SDR HD часто встречается BT.709, для UHD HDR — BT.2020 primaries вместе с соответствующей transfer-функцией, например PQ или HLG. Но ориентироваться нужно на реальные свойства мастера. Если файл был тонмаппирован в SDR, копировать старые HDR-метаданные нельзя: они уже не описывают изображение.

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

Mastering display и content light

Для HDR-контента доступны статические метаданные mastering display и content light. Они описывают характеристики мастеринг-дисплея и яркостные показатели контента. Это metadata: оно не делает SDR-изображение HDR и не изменяет пиксели. Значения должны быть получены из мастер-файла, технической спецификации проекта или корректного анализа, а не придуманы для совместимости.

Ошибочные MaxCLL/MaxFALL или mastering coordinates способны повлиять на тональное отображение в телевизорах и проигрывателях. Если достоверных данных нет, безопаснее не подставлять произвольные числа. В профессиональном конвейере метаданные хранят вместе с мастер-информацией и валидируют после mux в конечный контейнер.

Level и временные параметры AV1

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

Если нет требования конкретной платформы доставки, лучше не форсировать level случайным значением. Для OTT-профиля, вещательной системы или аппаратного чипа требования обычно описаны отдельно; тогда выбранный уровень сверяют с итоговым потоком после кодирования. Аналогично time-scale и параметры fps следует менять только при понимании временной базы.

Still picture mode

rav1e поддерживает режим still picture для AV1-потока из одного изображения. Это свойство кодировщика AV1 и не означает, что CLI автоматически создаёт контейнер AVIF из PNG или JPEG. Для AVIF нужны дополнительные операции: декодирование исходного изображения, цветовое преобразование и упаковка AV1-данных в HEIF/AVIF-структуру. Специализированные инструменты могут использовать библиотеку rav1e как backend, но это другой пользовательский интерфейс.

Если эксперимент проводится напрямую с Y4M из одного кадра, still picture mode позволяет формировать поток с соответствующей семантикой. Для массового преобразования изображений практичнее использовать программу, которая целиком понимает AVIF и метаданные изображений. Здесь важно не путать возможности библиотеки кодирования и возможности конкретного CLI.

Ограничение и пропуск кадров

--limit задаёт максимальное количество кадров для кодирования, а --skip позволяет пропустить часть входа. Эти параметры особенно полезны в лабораторных тестах. Можно взять один и тот же Y4M, перейти к проблемному фрагменту и быстро проверить влияние speed, quantizer или rate control, не обрабатывая весь материал.

rav1e long.y4m -o sample.ivf --skip 2400 --limit 300 --speed 6 --quantizer 90

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

Reconstruction: сохранение восстановленных кадров

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

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

PSNR и дополнительные метрики

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

PSNR измеряет среднеквадратичную ошибку и удобен своей простотой. SSIM и другие показатели оценивают структуру иначе. Ни одна метрика не гарантирует совпадения с человеческим восприятием на всех типах контента. Для пресета лучше использовать сочетание объективных измерений и визуального контроля на типичных сценах.

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

Verbose, quiet и диагностические логи

--verbose увеличивает детализацию вывода, а --quiet подавляет лишние сообщения. В интерактивной настройке verbose помогает увидеть параметры декодера Y4M, используемый уровень CPU features, число тайлов и настройки кодирования. В автоматизированном production-процессе, наоборот, слишком подробный лог может занимать много места, поэтому выбирают минимальный уровень, достаточный для диагностики.

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

Benchmark mode

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

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

Сохранение и загрузка конфигурации

В справке веток rav1e встречается подкоманда advanced с возможностями сохранения и загрузки конфигурации в TOML, а также генерацией shell completion. Эти функции относятся к расширенному интерфейсу CLI и могли меняться между сборками, поэтому перед включением их в production-скрипт нужно проверить rav1e help advanced именно у установленного бинарника.

Конфигурационный файл полезен, когда команда стала слишком длинной и один набор параметров используется многократно. Но сам файл должен версионироваться вместе со скриптом: изменение default-настроек между сборками не должно незаметно менять профиль. Хорошо также хранить рядом короткое описание цели — например 1080p SDR mezzanine test, а не только набор чисел.

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

Shell completion

Генерация completion помогает Bash, Zsh, Fish или PowerShell дополнять имена опций. Это удобство ввода, а не функция кодирования. В рабочем окружении completion снижает количество опечаток, но скрипты всё равно должны содержать полные параметры и не зависеть от настроек интерактивной оболочки.

Если генератор completion отсутствует или относится к advanced, который не работает в конкретной сборке, это никак не мешает базовому кодированию. Не стоит менять encoder-бинарник только ради автодополнения, если основной pipeline уже протестирован.

Использование librav1e через FFmpeg

FFmpeg может быть собран с encoder wrapper librav1e. В таком режиме не нужен Y4M pipe между отдельными процессами: libavcodec передаёт кадры библиотеке rav1e внутри одного процесса. Проверить наличие encoder можно командой ffmpeg -h encoder=librav1e. Если encoder отсутствует, это свойство конкретной сборки FFmpeg, а не ошибка файла.

Обёртка exposes основные параметры: qp, qmin, qmax, speed, tiles, tile-rows, tile-columns и rav1e-params. Последний позволяет передавать дополнительные пары key=value, разделённые двоеточием.

ffmpeg -i input.mkv -c:v librav1e -b:v 1800k -rav1e-params speed=6:low_latency=false -c:a copy output.mkv

Этот путь удобен, когда нужно одновременно фильтровать видео, кодировать аудио и сразу создавать контейнер. Отдельный rav1e.exe удобнее для прямого изучения CLI, тестирования официального бинарника и pipeline, где стадии намеренно разделены. Оба подхода используют один класс encoder-технологии, но набор доступных опций определяется ещё и версией/сборкой FFmpeg.

Проверка поддержки в FFmpeg

Команда справки encoder показывает, зарегистрирован ли librav1e и какие AVOptions доступны. Если FFmpeg отвечает Unknown encoder, установка отдельного rav1e.exe не добавит поддержку внутрь уже собранного FFmpeg автоматически. Нужна сборка FFmpeg, связанная с библиотекой rav1e, либо следует использовать внешний pipe.

При сравнении производительности отдельного CLI и wrapper желательно привести настройки к эквивалентным значениям. Параметр FFmpeg -b:v использует привычный синтаксис битрейта, а qp соответствует шкале rav1e 0–255. Нельзя сравнивать два запуска, если фактически они используют разные rate-control режимы.

C API и встраивание в приложения

Проект предоставляет C-совместимый API, библиотеку, заголовочный файл и pkg-config metadata. Такой вариант предназначен разработчикам, которые хотят подавать кадры из собственного приложения без запуска дочернего процесса. Библиотека позволяет создать конфигурацию, контекст encoder, отправлять кадры и получать пакеты AV1.

Встраивание даёт более прямой контроль над памятью и очередями, но требует аккуратной работы с pixel layout, stride, bit depth и жизненным циклом кадров. Ошибки в этих областях могут выглядеть как дефект кодировщика, хотя фактически приложение передало неверно организованные данные. Поэтому разработку начинают с минимального примера API и только потом подключают собственный источник кадров.

Для создания C API из исходников применяется cargo-c. На x86-64 сборка с ассемблерными оптимизациями требует NASM. Если библиотека устанавливается в нестандартный prefix, нужно согласовать пути include, library и pkg-config с системой сборки конечного приложения.

Rust API

Нативный Rust API предоставляет структуры конфигурации и контекст кодирования. В EncoderConfig находятся width, height, bit depth, chroma sampling, bitrate, quantizer, speed settings, tile rows/cols, low latency, intervals ключевых кадров, color description, mastering display, content light и другие параметры. Это позволяет встроить rav1e в Rust-приложение без преобразования настроек через строку CLI.

Тип пикселя связан с разрядностью: 8-битные кадры обычно представлены соответствующим типом, а более высокая глубина требует 16-битного контейнера значений. Плоскости Y, U и V передаются отдельно. Приложение обязано правильно вычислять размеры chroma-плоскостей для 4:2:0, 4:2:2 или 4:4:4.

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

Практический сценарий: качественный файл для последующего mux

Для готового фильма или ролика, где исходный контейнер уже содержит звук и субтитры, удобно разделить задачу на видеокодирование и упаковку. Сначала FFmpeg декодирует только видеодорожку и передаёт Y4M, rav1e создаёт IVF, затем второй вызов FFmpeg копирует AV1 без изменения и добавляет необходимые дорожки из исходника. Такая схема позволяет повторно менять аудиокодек или контейнер, не пересчитывая видео.

Рабочая последовательность может выглядеть так:

ffmpeg -i source.mkv -map 0:v:0 -pix_fmt yuv420p10le -f yuv4mpegpipe - | rav1e - -o video.ivf --speed 6 --quantizer 88
ffmpeg -i video.ivf -i source.mkv -map 0:v:0 -map 1:a? -map 1:s? -c:v copy -c:a copy -c:s copy final.mkv

Перед длинным кодированием тот же pipeline проверяют с ограниченным числом кадров. После mux отдельно убеждаются, что продолжительность видеодорожки совпадает со звуком и что выбранный контейнер корректно хранит AV1. Если возник рассинхрон, причину ищут в временной базе, fps или стадии подготовки кадров, а не в параметре квантования.

Практический сценарий: кодирование с заданным битрейтом

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

Нельзя оценивать итоговый размер только по имени параметра: после кодирования проверяют фактическую длительность и средний поток. Для грубой оценки размер видеоданных равен битрейт × длительность, но container overhead, аудио и субтитры добавляются отдельно. Двухпроходная схема помогает распределению, а не отменяет необходимость финальной проверки.

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

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

В таблицу результатов записывают speed, quantizer/bitrate, количество tiles, fps кодирования, размер IVF и субъективные замечания. Если рассчитываются метрики, их добавляют отдельными столбцами. После выбора двух-трёх профилей проводится длинный прогон, поскольку короткий отрывок не показывает стабильность rate control и тепловые ограничения машины.

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

В batch-скрипте rav1e удобно отделить подготовку параметров от запуска процесса. Для каждого файла формируют уникальные пути временного IVF, статистики двух проходов и логов. Нельзя использовать один и тот же pass.stat для параллельных задач: процессы перезапишут данные друг друга, и второй проход получит несоответствующую статистику.

Код возврата каждого этапа должен проверяться до запуска следующего. Если FFmpeg не смог декодировать источник, не следует продолжать mux пустого IVF. Аналогично, после неудачного rav1e нужно удалить или пометить неполный файл, иначе повторный запуск может принять его за готовый.

В именах временных файлов желательно использовать идентификатор задания, а не только исходное имя. Это защищает от совпадений при одинаковых basename в разных папках. После успешного mux временные Y4M/IVF/stat можно удалять, но лог и точные параметры лучше сохранить для воспроизводимости.

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

Для оценки CPU берут фиксированный Y4M и запускают несколько speed-профилей при одинаковых threads и tiles. Между прогонами полезно дать системе вернуться к обычной температуре, если процессор заметно throttling. Результат записывают как средний fps и общее время, а не максимальный кратковременный пик.

Если тест сравнивает generic и AVX2-сборку, остальные параметры должны совпадать. AVX2-бинарник нельзя запускать на CPU без AVX2. Если он завершается illegal instruction, это не повреждение видеоданных: выбран неподходящий набор инструкций.

Практический сценарий: низкая задержка

Для live-конвейера важен не только fps, но и то, сколько кадров накапливается между входом и выходом. --low-latency уменьшает зависимость от будущих кадров, но эффективность сжатия меняется. Сначала проверяют, способен ли encoder стабильно обрабатывать поток быстрее реального времени, затем измеряют фактическую end-to-end задержку вместе с capture, FFmpeg, mux и транспортом.

Если rav1e кодирует 30 fps-источник в среднем 31 fps, небольшой скачок сложности может создать очередь. Для live нужна запасная производительность, а не равенство среднему fps. В некоторых сценариях более быстрый --speed даёт более устойчивую задержку, даже если офлайн-качество при том же битрейте немного уступает более медленному режиму.

Практический сценарий: HDR без потери разрядности

HDR-процесс начинается с проверки источника. Нужно знать bit depth, primaries, transfer, matrix, range и статические метаданные. Если FFmpeg только декодирует и передаёт 10-битный Y4M, важно не вставить фильтр, который незаметно переводит его в 8 бит или меняет цветовое пространство. rav1e затем получает соответствующую разрядность и метаданные.

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

Практический сценарий: 4:4:4 для графики и текста

Для screen content мелкие цветные детали могут сильнее страдать от 4:2:0. Если цепочка воспроизведения поддерживает 4:4:4 AV1, можно сохранить исходную chroma detail и сравнить с 4:2:0. Но размер и совместимость могут измениться, поэтому такой профиль обычно предназначен для конкретной среды, а не для универсальной раздачи.

Тест должен включать тонкий цветной шрифт, пиксельную графику, линии интерфейса и контрастные границы. Если источник уже 4:2:0, преимуществ от апсемплинга почти не будет: потерянная исходная chroma-информация не восстанавливается.

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

Для сравнения кодировщиков важно зафиксировать входной Y4M, команды, версии бинарников, CPU, threads, tiles и критерий остановки. Если один encoder получает исходный MKV через собственный декодер, а другой — Y4M после FFmpeg, различия могут частично происходить от цветового преобразования или фильтрации.

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

Типичные ошибки и их исправление

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

Ошибка: rav1e не открывает MP4 или MKV

Это ожидаемое поведение: CLI принимает Y4M, а не произвольный медиаконтейнер. Следует декодировать видео через FFmpeg и передать -f yuv4mpegpipe либо заранее сохранить .y4m. Замена расширения .mp4 на .y4m ничего не конвертирует.

Ошибка: команда не найдена

Если оболочка сообщает, что rav1e не является командой, нужно проверить расположение бинарника и PATH. Для теста запускают полный путь. На Windows путь с пробелами заключают в кавычки. Если полный путь работает, проблема точно не относится к входному видео.

Ошибка: output file already exists

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

Ошибка: pipe завершается Broken pipe

Broken pipe означает, что процесс-получатель закрыл канал. Если rav1e отказался от входа из-за неверного Y4M, FFmpeg затем увидит закрытый stdout и тоже напечатает ошибку. Нужно читать лог обоих процессов и искать первую причину, а не последнюю строку. Самый надёжный тест — записать короткий Y4M в файл и запустить encoder отдельно.

Ошибка: Y4M распознан с неожиданной битностью

Проверяют -pix_fmt в FFmpeg и свойства исходника. Если команда явно содержит yuv420p, 10-битный источник будет приведён к 8 битам до rav1e. Для 10 бит нужен соответствующий формат, например yuv420p10le, и сборка FFmpeg должна уметь выводить его в Y4M.

Ошибка: неверные цвета или уровень чёрного

Проблема часто связана с range/primaries/transfer/matrix. Сначала сравнивают кадр до и после подготовки Y4M. Если уже Y4M выглядит неверно, менять metadata rav1e поздно — нужно исправлять преобразование FFmpeg. Если Y4M правильный, проверяют теги AV1 и конечного контейнера.

Ошибка: HDR выглядит как SDR или слишком тёмно

Проверяют, не потерялись ли PQ/HLG transfer characteristics, BT.2020 primaries, mastering display и content light. Также нужно убедиться, что проигрыватель действительно включает HDR path. Нельзя судить по одному SDR-монитору с неизвестным тонмаппингом.

Ошибка: процессор загружен не полностью

Сначала смотрят разрешение и тайлы. Для небольшого кадра один encoder может не масштабироваться на десятки потоков. Добавление разумного числа tiles увеличивает параллелизм. Затем проверяют --threads. Если используются pipe и тяжёлые фильтры, часть CPU может расходоваться FFmpeg, поэтому смотрят загрузку обоих процессов.

Ошибка: слишком много тайлов, а быстрее не стало

После определённого уровня overhead и ограничения алгоритма перестают окупаться. Возвращаются к меньшему числу tiles и сравнивают общее время. Оптимум зависит от разрешения и CPU. Нет смысла устанавливать число тайлов равным числу логических потоков без измерений.

Ошибка: AVX2-сборка падает сразу после запуска

Если процессор не поддерживает нужные инструкции, возможен illegal instruction. Используют generic или более совместимую сборку. Аналогичная проблема может возникнуть при переносе бинарника, собранного с target-cpu=native, на более старую машину. Такой бинарник оптимизирован под CPU, где его создавали.

Ошибка: скорость неожиданно очень низкая

Проверяют --speed, разрешение, bit depth, chroma, tiles и фоновые процессы. Speed 0 предназначен для очень тщательного поиска и может быть существенно медленнее средних значений. 4:4:4 и высокая разрядность увеличивают объём работы. Для диагностики запускают короткий отрывок на speed 8–10 и сравнивают.

Ошибка: результат значительно больше ожидаемого

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

Ошибка: битрейт сильно колеблется

Средний target bitrate не означает одинаковое количество битов в каждую секунду. Сложные сцены требуют больше, простые — меньше. Если транспорт накладывает ограничения на буфер, следует настраивать rate control с учётом reservoir и требований системы, а не пытаться сделать каждый GOP одинакового размера вручную.

Ошибка: двухпроходный режим даёт странный результат

Проверяют, что файл статистики создан именно первым проходом этого же входа, не перезаписан другой задачей и что фильтры FFmpeg между проходами идентичны. Затем сверяют bitrate и speed. В параллельном batch каждое задание должно иметь собственный stats-файл.

Ошибка: неправильная длительность

Причину ищут в fps и time base входного Y4M. Если FFmpeg изменил кадровую частоту, rav1e кодирует уже новую последовательность. После mux также проверяют timestamps контейнера. Квантование и speed не должны менять число кадров, если не используется явный limit/skip.

Ошибка: начало тестового фрагмента отличается от полного кодирования

Использование --skip создаёт отдельный запуск без истории reference frames полного ролика. Поэтому первые кадры короткого теста могут иметь иную структуру. Для точного анализа участка внутри полного encode можно кодировать более длинный диапазон с запасом перед интересующей сценой.

Ошибка: плеер не открывает IVF

IVF — простой контейнер, но не каждый пользовательский плеер ориентирован на него. Проверяют поток через современный AV1-декодер или remux в MKV/MP4 без перекодирования. Если remux работает, encoder-output, вероятно, исправен, а ограничение было на стороне проигрывателя или container demuxer.

Ошибка: после mux нет звука

rav1e создаёт только видеопоток. Звук нужно отдельно добавить из исходника или другого файла. В FFmpeg проверяют -map и кодек аудио. Если использовалось только -i video.ivf, аудиодорожки физически неоткуда взять.

Ошибка: FFmpeg пишет Unknown encoder 'librav1e'

Текущая сборка FFmpeg не связана с librav1e. Либо используют другой FFmpeg с поддержкой encoder, либо внешний rav1e через Y4M pipe. Наличие rav1e.exe рядом не меняет список libavcodec encoders.

Ошибка: monochrome Y4M не принимается

В официальной инструкции CLI отмечено ограничение monochrome color format для входного Y4M. Если источник одноканальный, его можно подготовить как поддерживаемый YUV-формат с нейтральными chroma-плоскостями либо использовать другую библиотечную цепочку, если цель действительно требует монохромного кодирования. Не стоит подделывать заголовок Y4M без корректных плоскостей.

Ошибка: тайлы не принимают указанное значение

Параметры rows/cols подчиняются требованиям формы и степеней двойки, а encoder может учитывать разрешение. Сверяют --help и начинают с малого числа. Невалидная геометрия — не повод менять видео: достаточно исправить аргумент.

Ошибка: ключевые кадры появляются слишком часто

Проверяют --min-keyint, --keyint и scene detection. Резкие монтажные склейки могут естественно приводить к дополнительным keyframes в допустимых пределах. Если внешний сегментатор требует строгой структуры, его требования нужно согласовать с параметрами rav1e, а при необходимости отключить автоматическую сценодетекцию осознанно.

Ошибка: ключевые кадры слишком редкие для перемотки

Уменьшают максимальный keyint, пересчитав его из желаемых секунд в кадры. При 60 fps для того же временного интервала число кадров будет выше, чем при 24 fps. Слишком маленький keyint увеличивает overhead, поэтому разумен компромисс между seekability и сжатием.

Ошибка: синтетическое зерно выглядит неестественно

Снижают photon-noise или убирают генерацию, затем сравнивают с источником. Если используется готовая grain table, убеждаются, что она рассчитана для этого материала. Проверяют декодер: разные визуальные результаты могут возникнуть, если один проигрыватель применяет film grain metadata, а другой нет.

Ошибка: метрики считаются слишком долго

Отключают --psnr и дополнительные metrics для production-запуска. Метрики нужны на тестовом наборе, а не обязательно на каждом файле. Внешний контроль качества можно выполнять выборочно после кодирования.

Ошибка: reconstruction съедает диск

Реконструированные YUV-кадры несжатые и могут быть во много раз больше IVF. Используют reconstruction только на коротком участке или направляют временный файл на диск с достаточным объёмом. После завершения анализа его удаляют.

Ошибка: результат отличается между машинами

Сверяют версии rav1e, параметры, сборки CPU, входной Y4M и число потоков. В исследовательском сценарии желательно фиксировать официальный бинарник или commit. Если одна машина использует wrapper FFmpeg, а другая отдельный CLI, сначала приводят интерфейсы к эквивалентным настройкам.

Ошибка: собственная сборка не видит NASM

На x86-64 ассемблерные оптимизации требуют NASM. Устанавливают подходящую версию и убеждаются, что исполняемый файл виден в PATH. Для диагностики можно отключить assembly-функции средствами сборки/окружения, но такой бинарник будет использовать другой путь исполнения.

Ошибка: библиотека C API не находится при запуске

Проверяют install prefix, library search path и способ линковки. Если dynamic library установлена в нестандартный каталог, загрузчик ОС должен знать этот путь. Это инфраструктурная проблема, а не ошибка битстрима. При распространении приложения нужно учитывать набор runtime-зависимостей выбранной схемы.

Ошибка: после обновления скрипт не принимает параметр

Сначала вызывают rav1e --help и rav1e help advanced, если использовались расширенные команды. CLI отдельных веток мог меняться. Надёжный production-процесс фиксирует версию binary и тестирует обновление отдельно, а не подменяет executable посреди серии кодирований.

Как читать прогресс rav1e

Строка прогресса содержит число обработанных кадров, скорость fps, битрейт, elapsed и оценку оставшегося времени/размера в зависимости от режима. Эти значения полезны прежде всего как индикаторы. В начале длинного encode оценка ETA нестабильна, потому что статистики ещё мало; по мере обработки она становится точнее.

Если fps резко падает на отдельных сценах, это не обязательно проблема: сложность кадров разная. Для производственного планирования смотрят на средний throughput всего файла. Если скорость падает постепенно на протяжении десятков минут, стоит проверить throttling и температуру CPU.

Финальная сводка по frame types и среднему QP помогает понять структуру результата. Если ожидался bitrate mode, а параметры показывают поведение постоянного quantizer, нужно вернуться к команде. Лог — самый быстрый способ заметить, что по ошибке запущен не тот пресет.

Организация каталогов проекта

Для большого числа заданий удобно разделить каталоги input, work, output и logs. В work попадают временные IVF и stats, в output — только финальные контейнеры. Тогда аварийное завершение не оставляет неполный файл рядом с готовыми результатами.

Если Y4M сохраняется на диск, его можно считать кэшем входных кадров. Один кэш используют для нескольких encoder-tests только если фильтры и цветовое преобразование должны быть одинаковыми. Имя файла полезно дополнять разрешением, bit depth и chroma, чтобы не перепутать 420p10 и 444p10.

Что проверять после кодирования

• число кадров и длительность результата относительно исходного задания;
• фактический средний битрейт или размер, если использовался target bitrate;
• bit depth и chroma sampling;
• color primaries, transfer, matrix и range;
• структуру keyframes, если она важна для seek или сегментов;
• воспроизведение несколькими AV1-декодерами;
• синхронизацию аудио после mux;
• наличие HDR/film-grain metadata, если они применялись.

Эти проверки не требуют перекодировать видео. Большинство выполняется анализатором контейнера и decoder probe. В случае обнаруженной ошибки сначала определяют, относится она к AV1-битстриму или к mux/metadata. Такой раздел помогает не переделывать долгий encode из-за проблемы, которую можно исправить простым remux.

Шпаргалка по основным параметрам rav1e

Ниже собраны параметры, которые чаще всего участвуют в практической настройке. Таблица не заменяет --help конкретной сборки: она объясняет назначение и типичные ошибки выбора. Если опция отсутствует в установленном бинарнике или называется иначе, приоритет имеет его собственная справка.

Параметр	Что регулирует	Когда менять	Что проверить
-o, --output	Файл с AV1 в IVF	Всегда задавать явный путь результата	Свободное место и отсутствие случайной перезаписи
-y	Разрешение перезаписи результата	В автоматизированном задании после проверки путей	Что скрипт не указывает важный существующий файл
--quantizer	Степень квантования 0–255	Когда приоритет — постоянное качество	Меньше число — выше качество и обычно больше размер
--min-quantizer	Нижняя граница квантования в bitrate mode	При осознанном ограничении rate control	Не зажата ли свобода распределения битов
--bitrate	Целевой видеобитрейт	Когда важен бюджет канала или размера	Единицы и фактический средний поток
--speed	Баланс вычислений и эффективности	Практически в каждом профиле	Реальное время encode на целевом CPU
--threads	Размер пула потоков	При контроле CPU или параллельных заданий	Не создаётся ли oversubscription
--tiles	Желаемое общее число тайлов	Для масштабирования на много ядер	Ускорение, размер и качество после изменения
--tile-rows	Число рядов тайлов	Когда нужна конкретная геометрия	Допустимое значение и ограничения разрешения
--tile-cols	Число столбцов тайлов	Для явного горизонтального деления	Не слишком ли мелкими стали области
--keyint	Максимальный интервал ключевых кадров	При требованиях seek/сегментации	Пересчёт кадров в секунды при текущем fps
--min-keyint	Минимальный интервал keyframes	Для ограничения слишком частых I-кадров	Совместимость со scene detection
--switch-frame-interval	Интервал switch frames	Для специальных потоковых структур	Действительно ли потребитель использует switch frames
--low-latency	Режим с меньшей временной задержкой	Live и интерактивные сценарии	Качество, throughput и end-to-end latency
--rdo-lookahead-frames	Глубину будущего контекста	При ручном балансе задержки и анализа	Память и задержку
--tune	Psychovisual или Psnr-направление оптимизации	При визуальном кодировании или метриках	Что метод оценки соответствует выбранной цели
--first-pass	Файл статистики первого прохода	Для многопроходного rate control	Уникальное имя на каждое задание
--second-pass	Статистику для второго прохода	После первого прохода того же входа	Идентичность входных кадров и фильтров
--reservoir-frame-delay	Горизонт буфера rate control	При особых требованиях к буферу	Задержку и колебания битрейта
--still	Still-picture семантику AV1	Для одноизображенческого AV1-потока	Не путать с готовым AVIF-контейнером
--photon-noise	Уровень синтетического зерна	На зернистом контенте после тестов	Естественность в декодере с film grain
--film-grain-table	Внешнюю таблицу зерна	Когда анализ зерна сделан отдельно	Соответствие таблицы конкретному ролику
--range	Limited/full range metadata	Если требуется явно описать уровни	Что metadata соответствует реальным пикселям
--primaries	Цветовые основные	SDR/HDR workflow с явным описанием	Соответствие мастер-файлу
--transfer	Передаточную характеристику	При сохранении PQ/HLG/SDR semantics	Что до rav1e не выполнен иной tone mapping
--matrix	Matrix coefficients	При явном цветоуправлении	Согласованность с YCbCr-преобразованием
--mastering-display	Статические mastering metadata	Для HDR при наличии достоверных значений	Не придуманы ли координаты/яркость
--content-light	MaxCLL/MaxFALL-подобные данные	Для HDR-профиля	Источник значений и перенос в конечный контейнер
--level	Уровень AV1	При требованиях платформы доставки	Соответствие разрешения, fps и битрейта
--limit	Число кодируемых кадров	Для быстрых тестов и диагностики	Что тест достаточно репрезентативен
--skip	Число пропускаемых входных кадров	Чтобы перейти к нужной сцене	Отличие контекста от полного encode
--reconstruction	Несжатые восстановленные кадры	Для отладки и внешних метрик	Свободное дисковое пространство
--psnr	Расчёт PSNR	В измерительных тестах	Дополнительное время обработки
--verbose	Подробный лог	Во время настройки и поиска ошибок	Объём логов в batch
--quiet	Минимальный вывод	В стабильной автоматизации	Не скрыта ли информация, нужная для диагностики

Как проектировать собственный пресет

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

Для файла без жёсткого bitrate budget разумная последовательность настройки такова: выбрать корректный Y4M, зафиксировать speed, подобрать quantizer на тестовых сценах, проверить tiles для CPU, затем настроить keyint и metadata. Для потока с заданным битрейтом вместо quantizer выбирают bitrate, при необходимости переходят к двухпроходному режиму, а затем проверяют buffer/latency ограничения.

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

Что rav1e делает сам, а что нужно делегировать

Задача	rav1e	Обычно выполняет другой инструмент
AV1-кодирование кадров	Да	—
Чтение Y4M	Да	—
Декодирование H.264/HEVC/VP9	Нет	FFmpeg или другой декодер
Чтение MP4/MKV как исходника	Не как штатный вход CLI	Демультиплексор/FFmpeg
Масштабирование и crop	Нет	Видео-фильтр до кодировщика
Изменение fps	Не как фильтр	Подготовительный этап
Кодирование аудио	Нет	Аудиокодировщик/FFmpeg
Субтитры	Нет	Muxer/FFmpeg
Создание MKV/MP4	Нет, CLI пишет IVF	Muxer
Выбор quantizer/bitrate/speed	Да	—
Tiles и threads	Да	—
Keyframe interval	Да	—
AV1 color metadata	Да	Контейнер также нужно проверить после mux
Film grain synthesis metadata	Да	Анализ зерна может выполняться отдельно
AVIF-контейнер	Не напрямую CLI	Специализированный AVIF-инструмент

Такая граница ответственности — не недостаток сама по себе, а модель Unix-подобного конвейера. Она становится неудобной, когда пользователь ожидает открыть произвольный медиофайл и одним окном получить готовый MP4. В такой задаче frontend на базе FFmpeg проще. Когда же нужны повторяемые encoder-тесты или интеграция в собственную систему, узкая роль rav1e даёт меньше скрытых этапов.

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

Прямые альтернативы rav1e различаются не только качеством AV1, но и интерфейсом, способом интеграции и областью оптимизации. В таблице сопоставлены программы, которые реально могут выполнять программное AV1-кодирование или предоставлять его как часть медиаконвейера.

Программа	Лучше подходит для	Главное ограничение
rav1e	CLI-конвейеров, экспериментов с AV1, Rust/C-интеграции и прямого контроля quantizer, speed, tiles и GOP	CLI принимает Y4M и пишет IVF; звук, фильтры и финальный mux требуют других инструментов
aomenc (libaom)	Эталонной экосистемы AOMedia, исследований AV1 и сценариев, где нужны параметры reference encoder	Большое число низкоуровневых настроек и высокая вычислительная стоимость на медленных режимах
SvtAv1EncApp (SVT-AV1)	Многопоточного CPU-кодирования AV1 с акцентом на высокий throughput и серверные нагрузки	Собственная шкала пресетов и параметров не переносится напрямую из rav1e
FFmpeg с libaom-av1 / libsvtav1 / librav1e	Полного транскодирования: чтения контейнеров, фильтров, аудио и mux в одном процессе	Набор AV1-возможностей зависит от того, с какими внешними библиотеками собран конкретный FFmpeg
HandBrake с AV1-энкодерами	Пользователей, которым нужен графический или пакетный интерфейс транскодера с фильтрами и готовым контейнером	Не предоставляет тот же прямой уровень CLI-контроля rav1e и зависит от доступных backend-энкодеров сборки

Практический вывод зависит от роли в процессе. Если задача — исследовать именно rav1e, встроить его библиотеку или управлять отдельным AV1-encoder через понятный CLI, его узкий интерфейс соответствует задаче. Если необходимо открыть MKV, обрезать изображение, перекодировать звук и сразу получить конечный контейнер, FFmpeg или HandBrake сокращают число внешних этапов. aomenc и SVT-AV1 относятся к той же категории AV1-кодировщиков, но используют собственные наборы компромиссов и настройки, поэтому пресеты нужно тестировать на одном входе, а не механически переводить числа.

Когда особенно удобен отдельный rav1e.exe

Отдельный бинарник удобен в воспроизводимых тестах. Он принимает подготовленный Y4M, поэтому декодирование не смешивается с измерением encoder. Можно заменить версию rav1e, не меняя FFmpeg, и сравнить bitstream/скорость на тех же кадрах. Аналогично можно тестировать generic, SSE4 и AVX2 сборки при одинаковом входе.

В CI отдельный executable легко запускать как отдельный этап. Лог, код возврата и выходной IVF однозначно относятся к encoder. Если интеграционный тест упал, проще понять, сломалось ли чтение Y4M, кодирование или последующий mux. В монолитной команде FFmpeg все этапы выводят сообщения в один журнал.

Когда удобнее librav1e внутри FFmpeg

Wrapper выигрывает, когда основная сложность находится вокруг кодировщика: несколько аудиодорожек, сложные фильтры, субтитры, chapter metadata и конечный Matroska/MP4. Передача кадров в библиотеку исключает внешний pipe, а настройки rav1e можно задавать через AVOptions и rav1e-params.

Но такой подход требует проверить конкретный FFmpeg build. Наличие encoder определяется тем, был ли FFmpeg скомпилирован с заголовками и библиотекой rav1e. В готовых пакетах набор внешних libraries различается. Поэтому production-скрипт должен сначала валидировать ffmpeg -h encoder=librav1e, а не предполагать поддержку по номеру версии FFmpeg.

Когда не стоит выбирать rav1e

Если нужен полностью графический процесс открыть файл — выбрать устройство — получить готовое видео, raw CLI потребует лишних шагов. Если критично аппаратное кодирование AV1 на GPU/ASIC, rav1e не является соответствующим hardware encoder. Если главная цель — AVIF-фотографии с EXIF/ICC/XMP, специализированный AVIF-инструмент лучше понимает контейнер изображения.

То же относится к live-сценарию, где CPU не успевает кодировать поток в реальном времени даже на быстром speed. Low latency не компенсирует нехватку вычислительной мощности. В таком случае выбирают более быстрый программный профиль, другой encoder или аппаратный путь в зависимости от требований к качеству и совместимости.

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

1. Проверить, что команда rav1e --version запускает ожидаемый бинарник.
2. Закодировать 100–300 кадров минимальной командой.
3. Убедиться, что Y4M имеет правильные width, height, fps, bit depth и chroma sampling.
4. Зафиксировать режим качества: quantizer или bitrate, не смешивая цели.
5. Проверить speed по фактическому fps на целевой машине.
6. Подобрать tiles, если CPU загружен плохо.
7. Проверить keyint относительно fps и требований seek/segmentation.
8. Для HDR сверить range, primaries, transfer, matrix, mastering и content light.
9. Для двух проходов дать заданию уникальный stats-файл.
10. Оценить свободное место для IVF, Y4M reconstruction и временных файлов.
11. Сохранить полную команду и лог рядом с идентификатором задания.
12. После encode декодировать тестовый результат и проверить визуально проблемные сцены.
13. После mux сверить длительность, звук, metadata и seek в конечном контейнере.

Этот порядок уменьшает риск обнаружить фундаментальную ошибку после нескольких часов вычислений. Он не требует специального GUI: каждая проверка выполняется тем же CLI и стандартными инструментами медиаконвейера.

Итоговая логика работы с rav1e

rav1e лучше воспринимать как специализированный AV1-движок с прозрачным командным интерфейсом. На входе ему нужны уже подготовленные кадры, на выходе получается AV1 в IVF, а всё окружение — декодирование исходного контейнера, фильтрация, звук и финальная упаковка — строится отдельно. Такая архитектура требует больше понимания pipeline, зато делает границы ответственности явными.

Для качества основным выбором становится quantizer либо target bitrate, для времени — speed, для масштабирования CPU — threads и tiles. Затем настраиваются структура ключевых кадров, latency, grain и metadata цвета. Если команда начинает содержать множество экспериментальных ключей, полезно вернуться к минимальному профилю и доказать пользу каждого отклонения измерением.

На практике надёжный процесс строится не вокруг одной лучшей команды, а вокруг короткого тестового набора, сохранённых логов и проверенного mux. Это особенно важно для AV1, где медленные пресеты способны сделать ошибку дорогой по времени. Сначала валидируется формат и цвет, затем производительность, затем качество, и только после этого запускается полный материал.