SVT-AV1 позволяет кодировать 8- и 10-битное видео в AV1 через SvtAv1EncApp, управляя качеством, битрейтом, пресетами скорости, структурой GOP, метаданными цвета и многопроходным режимом, а также подключать тот же кодировщик к FFmpeg для работы с обычными медиаконтейнерами.

Основной пользовательский инструмент SVT-AV1 — консольная программа SvtAv1EncApp. Она принимает необработанные YUV-кадры или поток Y4M, формирует AV1-битстрим в IVF либо в виде raw OBU и показывает параметры реально запущенного кодирования в терминале. Такой интерфейс требует внимательного отношения к формату входа, частоте кадров и глубине цвета, зато почти все значимые настройки кодировщика доступны явно: от CRF и целевого битрейта до структуры предсказания, адаптивного квантования, зерна, тайлов и цветовых метаданных.

Если исходник хранится в MP4, MKV, MOV, MPEG-TS или другом обычном контейнере, практичнее использовать SVT-AV1 через FFmpeg либо подать в SvtAv1EncApp подготовленный Y4M-поток. Сам кодировщик не выполняет монтаж, не выбирает аудиодорожки и не создаёт итоговый MKV с субтитрами: его задача — получить видеокадры, сжать их в AV1 и вернуть видеопоток. Поэтому надёжный рабочий процесс отделяет подготовку кадров, собственно кодирование и финальное мультиплексирование.

Что именно делает SVT-AV1

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

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

Важно не путать исходный SVT-AV1 с модифицированными ветками, чьи названия содержат PSY, Essential, HDR, Tritium и другие добавки. У таких сборок встречаются дополнительные или изменённые параметры, которых нет в основном проекте. Команда, найденная для форка, может быть отвергнута обычным SvtAv1EncApp или давать другой результат, поэтому параметры лучше сверять с выводом --help той сборки, которая фактически запускается.

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

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

Минимальная схема запуска выглядит так: источник задаётся через -i, выход — через -b. Для Y4M контейнер кадров несёт разрешение и частоту кадров в заголовке, поэтому команда может быть очень короткой. Для чистого YUV таких метаданных нет: необходимо дополнительно указать ширину, высоту, частоту кадров и правильную глубину. Ошибка хотя бы в одном из этих полей не является косметической — кодировщик начнёт разбивать байты на кадры не так, как задумано.

SvtAv1EncApp -i input.y4m -b output.ivf --crf 30 --preset 8

Флаг --progress регулирует подробность текущего вывода: нулевой уровень скрывает прогресс, первый оставляет стандартную информацию, второй делает вывод подробнее. Для пакетных сценариев существует --no-progress. Ошибки по умолчанию уходят в stderr, а --errlog позволяет перенаправить их в отдельный файл. Это удобно, если stdout занят битстримом или если задания запускаются планировщиком.

Подготовка входного видео: Y4M и raw YUV

SvtAv1EncApp принимает необработанное видео в Y4M или YUV. Это принципиальное ограничение интерфейса: нельзя просто передать ему произвольный H.264-файл в MKV и ожидать встроенного декодирования. Y4M удобнее для ручной работы, потому что заголовок описывает геометрию потока и его кадровую частоту. Raw YUV компактнее по структуре, но полностью полагается на параметры командной строки и имя файла ничего не гарантирует.

Для чистого YUV указывают -w и -h, а частоту кадров — парой --fps-num и --fps-denom. Например, 24000/1001 точно описывает киношные 23,976 кадра/с без округления. Параметр --input-depth принимает 8 или 10 и одновременно определяет глубину входного файла и выходного битстрима. Если 10-битный поток прочитать как 8-битный, границы кадров и значения выборок будут интерпретированы неверно.

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

При чтении из канала вместо имени файла можно использовать stdin или -. Это устраняет гигантский промежуточный YUV на диске: FFmpeg декодирует исходник, применяет фильтры и сразу отдаёт кадры SVT-AV1. Обратная сторона — обе программы оказываются частью одной цепочки. Если декодер завершается с ошибкой или получатель закрывает pipe, вторая сторона видит обрыв потока, поэтому диагностировать надо обе команды, а не только сообщение последнего процесса.

Пример подготовки 10-битного потока через FFmpeg

ffmpeg -i input.mkv -an -pix_fmt yuv420p10le -f yuv4mpegpipe - | \
SvtAv1EncApp -i stdin -b video.ivf --input-depth 10 --crf 28 --preset 6

В этой схеме FFmpeg отвечает за чтение контейнера и преобразование кадров, а SvtAv1EncApp получает Y4M. Параметр -an подчёркивает, что звук в эту ветку не нужен. Исходный аудиопоток можно затем скопировать отдельно при мультиплексировании. Для Windows синтаксис переноса строки и конвейера зависит от оболочки, но смысл остаётся тем же: stdout первого процесса подключается к stdin второго.

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

Выход: IVF, raw OBU и промежуточный битстрим

Ключ -b задаёт файл с сжатым видео. Формат определяется расширением .ivf или .obu; без явного выбора используется IVF. IVF — простой контейнер для видеобитстрима, удобный как промежуточный результат и для тестов. Raw OBU содержит открытые битовые единицы AV1 без оболочки IVF и включается расширением или ключом --obu. Отдельный --ivf принудительно выбирает IVF.

Ни IVF, ни raw OBU не заменяют привычный медиаконтейнер с аудио, субтитрами, главами и вложениями. Если нужен MKV, MP4 или WebM, после кодирования видеопоток мультиплексируют подходящим инструментом. На практике при работе с FFmpeg часто проще сразу вызвать libsvtav1 и получить конечный контейнер в одной команде; прямой SvtAv1EncApp остаётся удобным, когда нужен чистый эксперимент с параметрами кодировщика.

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

Пресеты скорости и вычислительная стоимость

--preset управляет компромиссом между скоростью кодирования и эффективностью сжатия. Пользовательские значения лежат в диапазоне 0–13; отрицательные пресеты предназначены для отладки. Чем выше номер, тем быстрее работает кодировщик и тем больше он отказывается от дорогих поисков и решений. Это не шкала качества в прямом смысле: CRF остаётся отдельным параметром, но одинаковый CRF на разных пресетах может дать различный битрейт и различную эффективность.

Для первичной настройки разумнее сначала выбрать класс скорости, который укладывается в доступное время, и только после этого настраивать CRF или битрейт. Бессмысленно подбирать идеальный CRF на очень медленном пресете, если полный фильм затем невозможно закончить за приемлемое время. Точно так же переход на максимально быстрый пресет ради нескольких минут экономии может увеличить размер архива настолько, что экономия CPU перестанет быть выгодной.

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

Параметр --fast-decode решает другую задачу: он подстраивает набор решений так, чтобы полученный поток было легче декодировать. У него есть уровни 1 и 2, причём второй сильнее ориентирован на скорость декодера. Это не синоним быстрого кодирования. Такой режим рассматривают, если целевые устройства имеют слабые AV1-декодеры или если важен запас производительности воспроизведения.

CRF: постоянное воспринимаемое качество без заданного размера

Для большинства файлового VOD-кодирования естественной отправной точкой является CRF. В SVT-AV1 режим --rc 0 используется и для CRF, и для CQP; различие определяется адаптивным квантованием. Явный --crf включает поведение, эквивалентное --rc 0 --aq-mode 2 с выбранным уровнем качества. Диапазон CRF — 1–70, допускается шаг 0,25. Меньшее число означает более бережное кодирование и обычно больший поток.

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

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

SvtAv1EncApp -i input.y4m -b output.ivf --preset 6 --crf 28

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

CQP и фиксированное квантование

CQP предназначен для режима, где адаптивное распределение квантования отключено. Современный ключ --cqp описывается как эквивалент --rc 0 --aq-mode 0 --qp x. Значения 1–70 допускают дробный шаг 0,25. Старый --qp остаётся отдельным параметром с диапазоном 1–63 и используется как начальный уровень QP; при его применении поведение --aq-mode сохраняет значение, заданное пользователем.

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

SVT-AV1 также умеет получать QP по кадрам из файла и работать с картой ROI. Эти инструменты нужны не для ручного подбора единственного числа, а для управляемого распределения качества во времени или по участкам кадра. ROI-карта задаёт смещения для блоков 64×64; при одновременном включении AQ mode 1 и ROI сегментный QP определяется картой ROI вместо обычной variance-based адаптации.

VBR, целевой битрейт и двухпроходное кодирование

Режим VBR включается --rc 1, а средняя цель задаётся --tbr в кбит/с. Параметр принимает также суффиксы для единиц. В отличие от CRF, здесь кодировщик старается распределить ограниченный бюджет битов по материалу. Такой подход нужен, когда важен прогнозируемый средний поток: например, для хранилища с заданной квотой или профиля доставки, где слишком большой файл нежелателен.

Для VBR доступен многопроходный режим. --passes 2 просит приложение выполнить два прохода, а --stats задаёт файл статистики. Отдельные проходы можно управлять через --pass 1 и --pass 2; второй проход разрешён для режимов, отличных от CRF, и должен читать корректный файл статистики. Это позволяет первому проходу изучить распределение сложности, а второму точнее расходовать битовый бюджет.

SvtAv1EncApp -i input.y4m -b output.ivf --rc 1 --tbr 4000 \
  --preset 5 --passes 2 --stats encode.stat

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

Параметры --minsection-pct и --maxsection-pct ограничивают относительный минимум и максимум битрейта GOP, а --recode-loop определяет, какие типы кадров могут быть перекодированы ради соблюдения ограничений. Это уже тонкая настройка rate control. Если базовый VBR попадает в цель и не создаёт нежелательных пиков, менять эти значения без измеримой причины не требуется.

CBR и сценарии с низкой задержкой

Постоянный битрейт выбирается --rc 2 вместе с --tbr. Это режим для ситуаций, где поток должен вести себя предсказуемо во времени, а не только иметь нужное среднее значение после завершения файла. В современных настройках SVT-AV1 CBR связан с механизмами, ориентированными на RTC и Low Delay: кодировщик может использовать перерасчёт QP и повторное кодирование кадра для удержания бюджета.

--rtc 1 включает быстрые настройки для real-time communication и принудительно переводит предсказание в low-delay структуру. Это меняет приоритеты: случайный доступ и глубокая перестановка кадров уступают задержке. Такой поток не следует оценивать теми же ожиданиями, что и медленное архивное кодирование random access. В RTC важны не только средняя эффективность, но и стабильность времени обработки кадра, пики битрейта и задержка очереди.

Инжектор кадров --inj и --inj-frm-rt позволяют подавать изображения в библиотеку с заданным темпом. Для обычного офлайн-файла это не нужно. В тесте real-time режима инжектор помогает приблизить скорость подачи к реальной частоте кадров и увидеть, успевает ли выбранный пресет. Если средняя скорость едва равна требуемой, отдельные сложные сцены всё равно могут нарушать бюджет времени, поэтому нужен запас.

GOP, ключевые кадры и структура предсказания

--keyint задаёт размер GOP в кадрах; в SvtAv1EncApp можно использовать суффикс секунд. Значение по умолчанию соответствует примерно пяти секундам, -1 означает практически бесконечный GOP и доступно для CRF, а нулевое значение трактуется аналогично. Увеличение интервала между ключевыми кадрами может повысить эффективность, но ухудшает произвольный доступ и усложняет нарезку по времени.

--irefresh-type выбирает тип обновления: open-GOP вариант FWD frame или закрытый GOP с KEY frame. Для контента, который позже будет сегментироваться на независимые фрагменты, ключевые кадры часто привязывают к границам сегментов. Важно согласовать правила кодировщика и упаковщика: сам факт наличия ключевого кадра не гарантирует, что внешний процесс нарежет поток именно в нужных местах.

Параметр --force-key-frames принудительно ставит ключевые кадры по списку спецификаторов кадров или секунд. В командных оболочках символ # может иметь служебный смысл, поэтому аргумент лучше заключать в кавычки. Для автоматической работы доступно --scd, управляющее обнаружением смен сцен, а --enable-dg разрешает Dynamic GOP, который адаптирует иерархическую структуру под материал.

--pred-struct выбирает all-intra, low delay или random access. Для типичного файлового видео применяется random access; low delay нужен, когда перестановка кадров и накопление будущего контекста нежелательны. --hierarchical-levels задаёт число уровней иерархии вплоть до пяти дополнительных уровней. Изменение этой структуры влияет на зависимости между кадрами, задержку, устойчивость к потерям и распределение QP.

Lookahead, temporal filtering и анализ будущих кадров

--lookahead задаёт число будущих кадров, доступных анализу сверх внутренних потребностей mini-GOP, temporal filtering и rate control. Значение -1 оставляет автоматический выбор, ноль убирает дополнительный lookahead, верхняя граница составляет 120. Больше контекста потенциально помогает принять решение о распределении битов и структуре, но увеличивает задержку и объём буферизации.

--enable-tf управляет временной фильтрацией ALT-REF кадров: 0 отключает её, 1 включает, 2 выбирает адаптивный вариант. Отдельно --enable-kf-tf включает MCTF для ключевых кадров. В чистом материале temporal filtering может дать полезную эффективность; в намеренно зернистом или текстурном видео слишком агрессивное сглаживание способно изменить характер источника. Поэтому этот блок тесно связан с настройками зерна и психовизуальной цели.

Флаг --enable-overlays добавляет overlay pictures как дополнительную опорную возможность для базового слоя. Это не наложение картинки в пользовательском смысле и не видеомонтаж. Параметр относится к внутренней структуре AV1, поэтому включать его ради визуального эффекта бессмысленно. Та же осторожность нужна с терминами alt-ref, mini-GOP и reference frame: это инструменты кодирования, а не элементы кадра.

Adaptive Quantization, variance boost и распределение качества

--aq-mode задаёт адаптивное квантование. Ноль отключает AQ, единица использует variance-based распределение через сегменты AV1, двойка — delta-Q подход, ориентированный на эффективность предсказания; именно режим 2 связан с обычным CRF. Изменяя AQ, пользователь меняет не только средний уровень QP, но и то, как качество перераспределяется между областями кадра.

--enable-variance-boost, --variance-boost-strength и --variance-octile дают дополнительный контроль над участками с выраженной локальной дисперсией. Сила имеет уровни от мягкого до агрессивного, а octile задаёт селективность алгоритма по блокам 8×8. Эти настройки полезно оценивать на текстурах, траве, волосах, ткани и мелком шумоподобном движении, а не на статичном градиенте.

--qp-scale-compress-strength сжимает разброс значений QP между временными слоями, делая качество внутри mini-GOP более ровным. Это может быть полезно, когда заметно дыхание детализации между кадрами. Однако любое выравнивание имеет цену: кодировщик получает меньше свободы расходовать биты там, где они эффективнее. Поэтому сначала нужно убедиться, что видимая проблема действительно связана с вариацией QP, а не с фильтрацией или неудачным CRF.

Для тёмных сцен существует --luminance-qp-bias, корректирующий кадровый QP в зависимости от средней яркости. --ac-bias влияет на внутреннюю rate-distortion метрику в сторону сохранения высокочастотной энергии и может помочь текстурам. Это уже не универсальные улучшатели: слишком сильное смещение способно перераспределить биты вопреки исходной цели, поэтому результат проверяют на собственном материале.

Матрицы квантования и ограничения QP

SVT-AV1 позволяет включить quantization matrices и задать диапазоны уровней для яркостной и цветностных составляющих. При плоской матрице коэффициенты имеют одинаковый вес; неплоские уровни меняют относительную стоимость пространственных частот. Документация отмечает, что более низкие уровни матрицы в CRF могут уменьшать битрейт ценой небольшого ухудшения качества, особенно при низком CRF.

Пара --qm-min/--qm-max ограничивает уровни яркости, а отдельные значения существуют для chroma. Кодировщик может выбирать матрицу по кадрам внутри разрешённого диапазона. Для обычного пользователя это тонкая настройка, которую лучше не смешивать сразу с variance boost, нестандартным tune и ручными qindex offsets: иначе трудно понять, какой механизм вызвал наблюдаемое изменение.

Отдельные смещения qindex для ключевых кадров и плоскостей дают ещё более низкоуровневый контроль. Их смысл раскрывается в исследовательском pipeline или при разработке собственной интеграции. Для типичной перекодировки фильма сначала достаточно пресета, CRF, структуры GOP, глубины и метаданных; детальные offsets стоит трогать только после появления конкретного измеряемого дефекта.

Режим Tune: что именно оптимизирует кодировщик

--tune выбирает целевую метрику или тип оптимизации. Доступны VQ, PSNR, SSIM, IQ для неподвижных изображений, MS-SSIM и VMAF для видео. Значение по умолчанию ориентировано на PSNR. Выбор tune не является косметическим ярлыком: он меняет внутренние решения кодировщика, поэтому два запуска с одинаковыми CRF и preset, но разным tune, не обязаны иметь одинаковый размер или одинаковый характер артефактов.

PSNR и SSIM удобны для воспроизводимых метрических экспериментов, но их максимум не всегда совпадает с субъективным предпочтением зрителя. VQ и другие режимы могут уделять больше внимания визуально воспринимаемым структурам. VMAF-ориентированная настройка имеет смысл, когда эта метрика действительно является частью критерия приёмки. Если сравнение делается по другой метрике, оптимизировать кодировщик под VMAF и затем объявлять победителя по PSNR методологически неправильно.

Для честного A/B теста tune фиксируют заранее, как и preset. Если задача — понять, какой tune лучше подходит конкретному классу видео, используют одинаковые исходники, сопоставимый битрейт или размер и несколько метрик плюс визуальную проверку. Сравнивать только одинаковый CRF недостаточно, потому что CRF не является общей абсолютной шкалой качества между разными внутренними целями.

Плёночное зерно и синтез grain в AV1

--film-grain включает механизм синтеза зерна и принимает уровень от 1 до 50; ноль отключает функцию. Идея AV1 состоит в том, чтобы не обязательно кодировать каждую случайную крупинку как обычную текстуру, а передать параметры модели, по которой декодер восстановит характер зерна. Это может существенно изменить соотношение размера и восприятия на плёнке, старых мастерах и намеренно шумных источниках.

--film-grain-denoise определяет, применяется ли денойзинг при включённом зерне. В текущих параметрах значение по умолчанию равно нулю: данные зерна могут передаваться в заголовке без включения соответствующего уровня денойзинга. --adaptive-film-grain позволяет выбирать блоки для синтеза адаптивно по разрешению и включён по умолчанию. Это помогает уменьшать заметность повторяющихся узоров.

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

Для внешней таблицы FGS существует параметр интерфейса библиотеки, но он не равнозначен обычному CLI-переключателю для любого сценария. Если pipeline строится непосредственно на SvtAv1Enc API, заранее подготовленная таблица может быть частью приложения; при работе с SvtAv1EncApp лучше ориентироваться на доступные в его --help опции.

Screen content: текст, интерфейсы и захват рабочего стола

Экранный контент отличается от камеры: много ровных областей, тонких линий, повторяющихся элементов и идеально резких букв. --scm управляет детектированием screen content: от отключения до режимов с Block Copy, Palette и контентно-адаптивным поведением, включая вариант, учитывающий anti-aliasing. По умолчанию используется адаптивный режим.

--enable-intrabc управляет Intra Block Copy — инструментом AV1 для повторного использования уже закодированных областей внутри кадра. Для интерфейсов, презентаций и игр с HUD повторяемость бывает высокой, поэтому такой механизм потенциально полезен. На обычном кино материале значение определяется пресетом и внутренними решениями; вручную форсировать его без теста не требуется.

При кодировании записи экрана особенно заметны ошибки 4:2:0: цветные тонкие шрифты и границы могут страдать ещё до AV1, на этапе преобразования цветности. SVT-AV1 сейчас ориентирован на YUV420, поэтому источник 4:4:4 неизбежно требует отдельного решения о понижении субсемплинга. Хороший ресайзер и корректная матрица преобразования иногда влияют на читаемость сильнее, чем переход между соседними CRF.

10-битное кодирование и high-bit-depth решения

SVT-AV1 принимает --input-depth 8 или 10. 10-битный pipeline полезен не только для HDR: больше уровней снижает риск полос на плавных градиентах и даёт кодеку более точное представление после цветовых преобразований. Однако 10-битный вход должен быть настоящим 10-битным YUV420-потоком; простая смена флага без конвертации байтов ломает интерпретацию данных.

--hbd-mds управляет глубиной решений mode decision для 10-битных входов: доступно поведение по пресету, полностью 8-битные, полностью 10-битные и гибридные вычисления. Это оптимизация внутренней стоимости. Она не превращает 8-битный источник в HDR и не меняет объявленную глубину выходного потока сама по себе. При сравнении режимов следует фиксировать исходные кадры и оценивать как скорость, так и качество.

Если FFmpeg подаёт кадры по pipe, пиксельный формат задают явно. Для 10 бит обычно нужен yuv420p10le, а в SvtAv1EncApp — --input-depth 10. Несогласованность этих двух сторон — одна из самых частых причин полос, странных цветов или немедленной ошибки. При Y4M часть информации присутствует в заголовке, но полагаться на догадки всё равно не стоит: вывод конфигурации при старте должен подтверждать ожидаемые 10 бит.

Цветовые метаданные SDR и HDR

Кодировщик умеет сигнализировать primaries, transfer characteristics, matrix coefficients, range и положение chroma samples. Это метаданные битстрима, а не цветокоррекция. Если кадры фактически BT.709, запись флагов BT.2020 не сделает их широким цветовым охватом — она лишь заставит декодер трактовать имеющиеся значения иначе. Поэтому метаданные должны описывать уже подготовленные пиксели.

Для SDR HD типичной комбинацией является BT.709 для primaries, transfer и matrix. Диапазон выбирают --color-range: studio или full. Значение по умолчанию — studio. Если исходник full-range, а кодировщик пометит его limited, возможны неверные уровни чёрного и белого при воспроизведении. Точно так же принудительный full-range для телевизионного limited источника не расширяет картинку, а меняет интерпретацию.

Для HDR10 могут понадобиться BT.2020 primaries, передаточная характеристика SMPTE ST 2084, соответствующая матрица, mastering display и Content Light Level. --mastering-display принимает координаты G/B/R, white point и максимальную/минимальную яркость, а --content-light — MaxCLL и MaxFALL. Эти числа нельзя сочинять по картинке: их берут из достоверных метаданных мастера или из измерительного процесса.

SvtAv1EncApp -i hdr.y4m -b hdr.ivf --input-depth 10 --crf 26 \
  --color-primaries bt2020 --transfer-characteristics smpte2084 \
  --matrix-coefficients bt2020-ncl --chroma-sample-position topleft

Mastering display и Content Light Level при необходимости добавляют отдельными параметрами. После мультиплексирования метаданные проверяют уже в конечном контейнере и битстриме: контейнерные теги и AV1 sequence metadata — разные уровни. Если упаковщик переписывает или теряет значения, правильная команда SVT-AV1 сама по себе не гарантирует корректный конечный файл.

Profile и Level: не путать возможность сигнализации с поддержкой входа

--profile предлагает main, high и professional, а --level — автоматический выбор или уровни AV1 от 2.0 до 7.3. Level описывает ограничения битстрима, связанные с разрешением, скоростью выборок и другими параметрами совместимости. В обычном случае разумно оставить автоматический level, если устройство или спецификация доставки не требует конкретного значения.

Наличие high/professional profile в таблице ключей не отменяет текущего ограничения интерфейса на YUV420. Нельзя сделать вывод professional значит 4:4:4 здесь поддерживается, не проверив реальную поддержку формата. Кодировщик может уметь сигнализировать профиль, но входная реализация конкретной сборки всё равно отвергнет неподдерживаемый цветовой формат.

Принудительно занижать level ради совместимости опасно: параметры потока могут перестать помещаться в объявленные пределы. Если целевой декодер требует определённый level, сначала рассчитывают допустимые разрешение, fps и bitrate, а затем проверяют поток валидатором/ffprobe. Level — это контракт с декодером, а не ручка качества.

Тайлы и параллелизм внутри кадра

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

Значения по умолчанию зависят от разрешения, поэтому ручное больше тайлов = быстрее не является универсальным правилом. На процессоре с большим числом ядер иногда выгоднее оставить автоматические решения и отрегулировать --lp, чем агрессивно делить каждый кадр. На стороне воспроизведения полезность тайлов зависит от конкретного декодера.

При диагностике масштабирования стоит измерять не только загрузку CPU в процентах. Если кодирование упирается в память, пропускную способность RAM или последовательный этап pipeline, добавление потоков не даст линейного ускорения. У больших 4K/8K кадров несколько одновременно обрабатываемых pictures могут заметно увеличить потребление памяти.

Level of Parallelism, потоки и память

--lp задаёт уровень параллелизма от 0 до 6. Это не число потоков. Кодировщик по этому уровню выбирает количество рабочих потоков и picture buffers; ноль разрешает автоматически учитывать число ядер. При повышении уровня обычно растут и параллельность, и память. В CRF уровни 4 и выше могут обрабатывать дополнительные mini-GOP одновременно, что ускоряет работу ценой особенно заметного роста памяти.

--pin ограничивает выполнение первыми N ядрами. Если --lp не указан, автоматический выбор параллелизма учитывает доступное процессу число ядер; если --lp задан явно, он сохраняется независимо от pin. Для более точного распределения отдельных заданий по ядрам в Linux применяют внешние механизмы affinity вроде taskset или numactl.

На машине, где параллельно кодируются несколько файлов, максимальный --lp у каждого процесса редко оптимален. Несколько экземпляров начинают бороться за cache и RAM. Часто стабильнее закрепить за каждым заданием часть ядер и умеренный уровень параллелизма. Это особенно важно на системах NUMA, где доступ к удалённой памяти может стать заметной частью стоимости.

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

Фильтры AV1: deblock, CDEF и restoration

SVT-AV1 управляет встроенными фильтрами, которые являются частью кодека: deblocking loop filter, CDEF и loop restoration. --enable-dlf имеет выключенное, обычное и более медленное точное поведение; --enable-cdef и --enable-restoration включают соответствующие стадии. Эти фильтры работают в контуре кодирования/декодирования и отличаются от постфильтров видеоредактора.

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

Если цель — сохранить природное зерно, желание отключить все сглаживающие механизмы понятно, но AV1 имеет отдельный film grain synthesis. Иногда выгоднее дать кодеку очистить шум и затем синтезировать зерно, чем кодировать каждый шумовой компонент как сигнал. В другом материале это может изменить фактуру слишком сильно. Нужен A/B тест исходного фрагмента, а не универсальная рецептура.

Super-resolution и reference scaling

В параметрах есть AV1 super-resolution и механизмы reference scaling. --superres-mode выбирает стратегию, а знаменатели --superres-denom и --superres-kf-denom определяют масштаб для обычных и ключевых кадров в соответствующих режимах. Значение 8 означает отсутствие уменьшения, 16 — масштаб примерно в половину по соответствующей формуле AV1.

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

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

Статистика, PSNR, SSIM и reconstructed YUV

--enable-stat-report 1 включает расчёт PSNR и SSIM по завершении кодирования. --stat-file записывает покадровую статистику. Это удобно для регрессионных тестов и поиска конкретных кадров, на которых качество проваливается. Метрики считаются относительно входных кадров того формата, который реально получил кодировщик, поэтому предварительный ресайз или конвертация должны быть одинаковыми во всех сравниваемых запусках.

Ключ -o сохраняет reconstructed YUV. Такой файл огромен, но позволяет анализировать именно декодированное представление, которое использует кодировщик, без зависимости от внешнего AV1-декодера. Для массовой работы reconstruction обычно не нужен; его включают для отладки, разработки и точного сравнения, а после эксперимента удаляют.

PSNR и SSIM полезны, но не исчерпывают визуальную оценку. Они могут предпочесть более гладкую картинку там, где человек ценит текстуру, или иначе реагировать на зерно. Режим --tune дополнительно меняет то, под какую цель оптимизируется кодировщик. Поэтому таблица метрик должна сопровождаться визуальной проверкой сцен, где различия реально заметны.

Конфигурационный файл и приоритет параметров

Вместо длинной командной строки часть параметров можно хранить в конфигурационном файле и передать через -c. Поддерживаются те опции, для которых в таблице документации определено имя configuration file parameter. Командная строка имеет приоритет при конфликте, поэтому общий файл удобно использовать как базовый профиль, а CRF, имя входа и выхода переопределять в конкретном задании.

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

--svtav1-params предлагает другой способ сгруппировать настройки: строка key=value, разделённая двоеточиями, где ключи соответствуют CLI-именам без --. Этот синтаксис особенно знаком пользователям интеграций через FFmpeg. Документация предупреждает, что проверка дублированных ключей отсутствует, поэтому один и тот же параметр не следует незаметно задавать дважды с разными значениями.

SVT-AV1 в FFmpeg

FFmpeg обращается к библиотеке через кодировщик libsvtav1. Это наиболее удобный путь для обычных медиофайлов: FFmpeg декодирует вход, выбирает нужный video stream, применяет масштабирование или цветовое преобразование, передаёт кадры в SVT-AV1, а затем мультиплексирует AV1 вместе со звуком и субтитрами. В результате пользователю не нужен промежуточный Y4M.

ffmpeg -i input.mkv -map 0:v:0 -map 0:a? \
  -c:v libsvtav1 -preset 6 -crf 28 -c:a copy output.mkv

Конкретные имена AVOptions зависят от сборки FFmpeg. Если необходим параметр, который не вынесен отдельным ключом FFmpeg, его часто можно передать через -svtav1-params в виде списка key=value. Перед пакетной очередью следует выполнить ffmpeg -h encoder=libsvtav1 и проверить, что нужные опции поддерживает именно установленная связка FFmpeg и библиотеки.

Главное преимущество такой интеграции — контейнер и звук. Например, аудиодорожку можно скопировать без перекодирования, а видео отправить в AV1. Но это также добавляет уровень абстракции: при ошибке неизвестного параметра надо выяснить, кто её выдал — FFmpeg, wrapper libsvtav1 или сама библиотека. Для спорной опции полезно воспроизвести проблему на SvtAv1EncApp с минимальным Y4M.

Не следует автоматически переносить командные строки из модифицированных сборок SVT-AV1 в официальный libsvtav1. FFmpeg примет строку только в той мере, в какой подключённая библиотека знает эти ключи. Особенно осторожно надо относиться к названиям психовизуальных параметров, встречающимся в сторонних ветках.

Мультиплексирование в MKV, MP4 и WebM

Если видео сначала создано в IVF, следующий этап — поместить его в конечный контейнер. Matroska обычно удобен для сложного состава дорожек, глав и вложений; MP4 востребован в совместимых воспроизводящих цепочках; WebM накладывает собственные ограничения на наборы дорожек и метаданные. SVT-AV1 не решает, какой контейнер нужен проекту — это определяется целевой системой.

При remux видеопоток не следует повторно кодировать: мультиплексор должен копировать уже готовый AV1. Звук можно скопировать из исходника или перекодировать отдельно. Если синхронизация нарушилась, проверяют timestamp/таймбазу и кадровую частоту, с которой видеопоток был сформирован. Особенно легко получить ошибку при raw YUV, где fps был задан неверно ещё до SVT-AV1.

Для сегментированных потоков ключевые кадры и GOP планируют до кодирования. Упаковщик не может мгновенно превратить произвольный inter frame в независимую точку входа без перекодирования. Поэтому длительность сегмента, keyint и принудительные ключевые кадры являются частью одного проекта, хотя выполняются разными программами.

Сборка и проверка после установки

Если готового пакета для нужной платформы нет, SVT-AV1 собирают из исходного репозитория через CMake. В результате нужны как минимум исполняемый SvtAv1EncApp и соответствующая библиотека SVT-AV1. На Windows приложение должно находить DLL, с которой было собрано; простое копирование одного EXE из чужого каталога может закончиться ошибкой загрузчика до появления справки кодировщика.

Проверка установки не должна начинаться с многочасового фильма. Сначала выполняют --version, затем --help, после чего кодируют короткий Y4M. Если программа стартует, но падает на конкретном CPU, проверяют архитектуру сборки и поддерживаемый набор инструкций. Параметр --asm умеет ограничивать SIMD-уровень на x86 или Arm и полезен для диагностики, хотя намеренное снижение SIMD обычно уменьшает скорость.

32-битная сборка проектом не поддерживается. Для современного бинарного пакета следует использовать 64-битную среду. Если пакетный менеджер устанавливает одновременно библиотеку и приложение, это предпочтительнее ручного смешивания файлов разных сборок: ABI и имя DLL/so должны соответствовать приложению, которое их загружает.

Как читать стартовый вывод SvtAv1EncApp

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

В блоке конфигурации проверяют width/height, fps, bit depth, preset/tune/pred structure, GOP и rate control. Если ожидался 10-битный 24 fps материал, а вывод показывает 8 бит или 60 fps, кодирование лучше остановить сразу. Дожидаться конца ради проверки размера бессмысленно: ошибка находится во входной интерпретации.

Скорость в кадрах в секунду оценивают относительно реального fps. Для файла 24p показатель 12 fps означает примерно половину realtime, но полный срок зависит от длины и изменения сложности сцен. На старте кэш, заполнение pipeline и небольшой sample дают нестабильную оценку, поэтому прогноз по первым десяткам кадров неточен.

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

Для архива, где важны размер и качество, рабочий процесс обычно начинается с lossless или качественного исходника, 10-битного Y4M/pipe и random access структуры. Пресет выбирают по доступному времени, затем подбирают CRF на нескольких сценах. Если материал зернистый, отдельно сравнивают сохранение естественного шума и film grain synthesis. Цветовые метаданные переносят только после проверки источника.

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

Хорошая архивная команда должна быть воспроизводимой. Вместе с результатом сохраняют строку запуска, версию библиотеки, cfg и информацию о предварительной обработке. Одного имени вроде CRF28 недостаточно: тот же CRF на другом preset или tune может дать другой поток.

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

Когда хранилище или канал задают средний бюджет, вместо CRF используют VBR. Целевой --tbr рассчитывают из допустимого размера и длительности, оставляя место звуку и контейнеру. Для более точного распределения по длинному ролику применяют два прохода. Первый собирает статистику, второй использует её при выделении битов сложным сценам.

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

Если итоговый размер систематически не попадает в ожидаемый бюджет, сначала проверяют, что действительно включён --rc 1, а единицы --tbr поняты правильно. Затем исключают влияние обрезанного теста, повторения кадров из-за неверного -n и лишнего повторного кодирования на стадии mux.

Практический сценарий: запись экрана

Для скринкаста важны читаемость мелкого текста и резкие однотонные границы. Перед кодированием источник приводят к YUV420 осознанным преобразованием, а затем оставляют adaptive screen content mode или тестируют более явный SCM. Если интерфейс содержит много повторяющихся плиток и окон, IntraBC и palette coding могут быть полезны.

Слишком низкий битрейт часто проявляется цветными ореолами вокруг шрифта и пульсацией тонких линий. Увеличение CRF-качества помогает не всегда, если основной ущерб уже нанесён chroma subsampling. Поэтому проверяют как настройки конвертации RGB→YUV, так и сам AV1. Для технической документации иногда лучше уменьшить частоту кадров, чем разрушать текст ради сохранения 60 fps в том же битовом бюджете.

Если запись должна передаваться интерактивно, условия меняются: low delay/RTC, CBR и быстрый preset важнее максимальной файловой эффективности. Для заранее записанного урока можно позволить random access и медленнее кодировать. Нельзя переносить один профиль между этими задачами только потому, что обе содержат экран.

Практический сценарий: HDR10

HDR-процесс начинается не с флагов SVT-AV1, а с проверки 10-битного исходника, реальных primaries/transfer/matrix и mastering metadata. Кадры передаются как 10-битный YUV420, а кодировщику сообщается --input-depth 10. Затем устанавливаются BT.2020, PQ и корректная матрица. MaxCLL/MaxFALL и mastering display копируют только из достоверного источника.

После кодирования поток проверяют декодером, который умеет AV1 HDR и корректно интерпретирует metadata. Затем проверяют уже финальный контейнер: иногда упаковщик хранит дополнительные поля или меняет способ представления служебных данных. Если телевизор отображает HDR как SDR, причина может находиться в битстриме, контейнере, HDMI-цепочке или самом плеере; менять CRF в такой ситуации бессмысленно.

Для HDR особенно важно не допустить случайного преобразования в 8 бит внутри FFmpeg-filtergraph. Явный pix_fmt перед libsvtav1 или Y4M-pipe помогает сделать цепочку прозрачной. Если используются фильтры масштабирования/тонмаппинга, их параметры документируют отдельно от настроек SVT-AV1.

Ошибки входа: неверные размеры, fps и глубина

Если raw YUV задан с неправильной шириной или высотой, кодировщик не имеет способа увидеть истинную геометрию. Он просто будет считать заданное количество байтов кадром. Результатом становятся смещённые плоскости, повторяющиеся участки, неверное количество кадров или ранний конец. Проверяют точный pixel format, размеры и формулу размера кадра для YUV420.

Неверный fps не меняет сами выборки, но меняет временную шкалу и битрейт в пересчёте на секунду. Файл 24000/1001, ошибочно объявленный как 60 fps, после mux может стать заметно короче и изменить rate-control условия. При Y4M эти параметры читаются из заголовка, поэтому его удобно использовать как самодокументируемый pipe.

При путанице 8/10 бит изображение обычно ломается гораздо сильнее. 10-битный little-endian поток содержит выборки по 16-битным словам, и чтение как 8 бит полностью меняет раскладку. Сверяют --input-depth, pix_fmt на стороне FFmpeg и строку bit-depth в стартовом логе.

Ошибки параметров и несовместимые команды

Сообщение об неизвестном ключе чаще всего означает одно из трёх: команда написана для другой версии основного проекта, для стороннего форка или для FFmpeg-wrapper, а не для SvtAv1EncApp. Решение начинается с --help. Поиск похожего нового имени вслепую опасен, потому что измениться могла не только орфография, но и семантика.

Современные сборки могут отвергать старую форму длинных параметров с одиночным дефисом. Если в старом примере встречается -keyint или похожая запись, проверяют текущий синтаксис с двойным --. Однобуквенные параметры вроде -i, -b, -w остаются отдельной категорией.

Если ключ передаётся через --svtav1-params, из его имени убирают ведущие -- и соблюдают формат key=value:key=value. Дублирование ключа не следует использовать как способ последний победит: документация не обещает полноценной проверки дублей. Лучше сформировать однозначную строку.

Broken pipe, остановка конвейера и нулевой выход

В цепочке FFmpeg → Y4M → SvtAv1EncApp сообщение broken pipe не обязательно говорит, что сломан FFmpeg. Оно означает, что процесс-получатель перестал читать канал. Причиной может быть неверный параметр SVT-AV1, нехватка памяти, ошибка библиотеки или ручная остановка. Нужно посмотреть stderr обоих процессов и найти первое сообщение, появившееся до обрыва.

Обратный случай — SVT-AV1 пишет в stdout, а мультиплексор завершается раньше. Тогда кодировщик получает ошибку записи. Проверяют, какой формат ожидает принимающая сторона и не попал ли текстовый лог в бинарный канал. Для диагностики полезно временно писать IVF в обычный файл: если он создаётся корректно, проблема находится в pipe или mux.

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

Нехватка памяти и чрезмерный параллелизм

AV1 на высоком разрешении может потреблять значительную память, особенно при высоком --lp, длинном анализе и нескольких параллельных заданиях. Если процесс завершается на 4K/8K, но стабилен на 1080p, проверяют пик RAM и swap/pagefile. Недостаточно смотреть только среднее потребление: буферы могут расти при определённой структуре pipeline.

Первый способ снизить давление — уменьшить --lp и число одновременно кодируемых файлов. В CRF высокие уровни параллелизма могут держать больше mini-GOP одновременно. Второй способ — исключить ненужный reconstructed output и чрезмерную буферизацию входа --nb. Третий — убедиться, что не создаётся гигантский YUV в памяти внешней оболочкой.

Если система имеет много ядер, но мало памяти на ядро, максимальный throughput часто достигается несколькими умеренными заданиями, а не одним экстремально распараллеленным. Это измеряется на реальной машине: архитектура CPU, NUMA и пропускная способность памяти сильно влияют на масштабирование.

Почему выходной файл не открывается в плеере

Сначала определяют, что именно было создано. IVF и raw OBU — не то же самое, что MKV/MP4. Некоторые плееры умеют открывать IVF напрямую, другие ожидают полноценный контейнер. Если файл назван .mkv, но SvtAv1EncApp записал в него IVF-битстрим, одно расширение не превращает его в Matroska.

Далее проверяют AV1-декодер. Поток может быть исправен, но конкретный плеер или аппаратный декодер не поддерживает профиль, уровень, 10 бит или определённые инструменты. --fast-decode может облегчить декодирование, но не исправляет отсутствие AV1 в принципе. Для диагностики используют программный декодер и независимый анализ битстрима.

Если проблема возникает только после mux, сравнивают исходный IVF и контейнер. Ошибочная временная база, потерянные extradata/sequence headers или несовместимая версия упаковщика могут нарушить воспроизведение при корректном видеопотоке. Повторное кодирование в такой ситуации — лишняя операция.

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

Оптимизация SVT-AV1 эффективнее, когда меняется одна группа параметров за раз. Сначала фиксируют preprocessing, preset, tune и режим rate control. Затем подбирают CRF или bitrate. После этого, если есть конкретная проблема, тестируют film grain, screen-content, fast-decode или тонкие AQ-параметры. Одновременное изменение десяти флагов лишает эксперимент причинно-следственной связи.

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

Для автоматизации создают таблицу с командой, временем, размером, средним битрейтом, PSNR/SSIM и внешними метриками. Визуальные замечания пишут отдельно. Такой журнал быстро показывает, какие параметры реально дают эффект на вашем контенте, а какие лишь усложняют команду.

Точная настройка ограничений битрейта в CRF

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

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

После кодирования ограничение проверяют анализатором по коротким временным окнам, а не только по общему среднему битрейту файла. Контейнерный bitrate из MediaInfo или ffprobe может быть усреднён по всей длительности и не показать пиков. Если площадка задаёт VBV-подобные требования или конкретный maximum instantaneous rate, нужно сверять именно её методику расчёта, потому что одно число --mbr не заменяет спецификацию доставки.

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

Scene change detection и принудительные точки доступа

Автоматическое обнаружение смен сцен через --scd решает отличную от фиксированного keyint задачу. Keyint задаёт максимально или регулярно ожидаемый ритм GOP, а scene change detection пытается распознать содержательную границу, где предсказание из предыдущей сцены мало полезно. На монтаже с резкими склейками это может улучшить структуру потока, но наличие SCD не означает, что каждая монтажная склейка станет удобной точкой сегментации.

Если точки доступа заранее известны — например, HLS/DASH сегменты должны начинаться каждые две секунды — надёжнее сочетать разумный keyint с --force-key-frames. В спецификаторах можно указывать кадры и время. При генерации строки из скрипта следует внимательно экранировать символы, чтобы shell не отрезал часть аргумента как комментарий или управляющую конструкцию.

Dynamic GOP через --enable-dg меняет иерархию в зависимости от содержания. Это полезно для эффективности, но делает структуру менее механически предсказуемой. Если downstream-инструмент ожидает жёстко фиксированную иерархию, Dynamic GOP следует сначала проверить на совместимость. В вещательном или тестовом pipeline воспроизводимость структуры иногда важнее небольшого выигрыша эффективности.

--startup-mg-size отдельно задаёт mini-GOP в начале после key frame. Такой параметр нужен для тонкой настройки перехода от точки доступа к обычной иерархии; в пользовательском файле он редко является первым рычагом. Если нет конкретного требования к latency или эталонной структуре, автоматическое поведение обычно безопаснее ручной перестройки.

All-intra и кодирование отдельных кадров

При --pred-struct 0 поток строится как all-intra: каждый кадр кодируется без межкадрового предсказания. Это резко меняет задачу. Сжатие становится менее эффективным для обычного видео, зато каждый кадр независим, упрощаются произвольный доступ и некоторые монтажные процессы. Такой режим применяют там, где независимость кадров ценнее минимального размера.

Параметр --tune 3 описан как IQ для still image only. Его не следует автоматически использовать для обычной последовательности только потому, что кадры похожи на фотографии. Оптимизация неподвижного изображения и оптимизация видео имеют разные допущения. Для фильма или анимации выбирают режим, предназначенный для video, если только эксперимент не преследует специально другую цель.

All-intra удобно использовать для диагностических сравнений spatial-инструментов: исчезает влияние движения и структуры референсов. Но размер такого теста нельзя переносить на random access. Если один кадр в all-intra выглядит лучше, это ещё не означает, что та же настройка даст лучший общий VOD-битстрим при том же среднем потоке.

Для последовательности изображений важно точно задать fps и порядок кадров ещё до SVT-AV1. Кодировщик получает поток изображений, но не управляет сортировкой исходных PNG/JPEG. Эту работу обычно выполняет FFmpeg или иной загрузчик, который формирует Y4M.

ROI-карты для областей повышенного внимания

Region Of Interest позволяет заранее указать, какие области кадра должны получить другое квантование. Формат карты SVT-AV1 описывает смещения QP по блокам 64×64 для конкретных номеров кадров. Это полезно в AR/VR, интерфейсах, видеоконференциях и машинном зрении, где известная область важнее остального изображения. Карта не распознаёт объект сама — её создаёт внешняя система.

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

При --aq-mode 1 и активной ROI карте сегментный QP определяется ROI вместо variance-based решения. Это важное взаимодействие: нельзя считать, что оба механизма просто складывают свои преимущества. Перед внедрением карты нужно знать, какой AQ режим используется профилем и не меняется ли он через CRF или другой ключ.

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

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

--nb позволяет буферизовать заданное число входных кадров в памяти и кодировать только их. В тестовой лаборатории это помогает исключить дисковый I/O из части измерений и многократно прогонять фиксированный набор кадров. Но стоимость — RAM: необработанный 4K 10-bit YUV420 занимает значительно больше места, чем сжатый исходник.

Если --nb используется для benchmark, в отчёте нужно явно писать его значение. Иначе сравнение с запуском, читающим с медленного сетевого диска, будет приписывать кодировщику разницу, созданную подсистемой хранения. Для реального production pipeline наоборот важно измерять end-to-end скорость вместе с декодированием и подачей кадров.

Параметры -n и --skip позволяют быстро формировать тестовые участки из одного Y4M. Однако один участок редко представляет весь фильм. Лучше иметь несколько независимых выборок с разным содержанием и одинаковой длительностью. Тогда случайная особенность одной сцены не определит выбор preset или CRF для всей библиотеки.

При автоматическом повторении тестов файлы вывода и статистики должны иметь уникальные имена. Перезапись IVF допустима только если скрипт проверяет код возврата предыдущего запуска. Иначе старый успешный файл может остаться на диске после нового неудачного задания и быть ошибочно принят за свежий результат.

Ограничение SIMD через --asm

SVT-AV1 использует оптимизированные SIMD-пути. --asm позволяет ограничить выбранный набор инструкций: на x86 перечислены уровни от C/MMX/SSE до AVX2 и AVX-512 вариантов, на Arm — NEON и более новые расширения. В обычной работе оставляют максимальный автоматически доступный уровень, потому что именно оптимизированный код обеспечивает ожидаемую производительность.

Ручное ограничение полезно при диагностике нестабильной сборки или для воспроизводимого сравнения процессоров на общей инструкции. Например, если ошибка появляется только с определённым AVX-512 путём, запуск с более низким уровнем помогает локализовать проблему. Но это временный диагностический шаг, а не настройка качества: математическая цель кодирования от выбора SIMD не должна принципиально меняться.

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

При сравнении производительности важно указывать архитектуру и SIMD, иначе цифры fps плохо переносимы. Даже одинаковое число физических ядер у разных поколений CPU не означает одинаковую скорость SVT-AV1.

Пакетная очередь и несколько экземпляров кодировщика

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

Очередь строят с учётом физических ядер, объёма RAM и разрешения. Один практический подход — сначала измерить одиночное 1080p и 4K задание при нескольких --lp, затем подобрать число одновременных процессов, при котором суммарный fps растёт. После точки насыщения дальнейший параллелизм только увеличивает latency каждого файла.

На NUMA-серверах процессы полезно закреплять за узлами памяти. В Linux внешние средства affinity дают больше контроля, чем простой --pin, потому что позволяют выбирать не первые N ядер, а конкретный набор. При этом --lp задают так, чтобы внутренний pipeline не создавал чрезмерно много буферов для выделенной группы.

Журналы хранят отдельно. Минимальный log для каждого задания содержит команду, stdout/stderr, версию библиотеки, время начала/окончания, код возврата и размер результата. Это даёт возможность отличить медленный encode от зависшего процесса и автоматически повторить только неудачные файлы.

Проверка выходного AV1 перед удалением исходника

Успешный код возврата ещё не является достаточной проверкой архива. Сначала декодируют итоговый AV1 целиком или хотя бы запускают проверку ошибок декодера по всей длительности. Затем сравнивают длительность и ожидаемое количество кадров. Для raw/Y4M workflow особенно важно убедиться, что ни один кадр не потерян из-за раннего закрытия pipe.

Второй уровень — проверка заголовков: профиль, level, bit depth, разрешение, fps и цветовые поля должны совпадать с проектом. Если использовались HDR metadata, проверяют mastering display и content light. Для контейнера дополнительно проверяют time base, audio streams, subtitles и start time.

Третий уровень — выборочная визуальная проверка. Смотрят начало и конец, точки склеек, тёмные сцены, быстрое движение, зерно и титры. Если включён film grain synthesis, используют декодер, который точно его применяет, иначе оценка будет неполной. Если нужен аппаратный playback, отдельный прогон выполняют на целевом устройстве.

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

Почему одинаковый CRF даёт разные размеры

CRF — не целевой bitrate. Кодировщик оценивает содержание и распределяет квантование так, чтобы следовать выбранной модели качества. Шум, зерно, вода, листья, толпа, быстрый панорамный кадр и сложные текстуры требуют больше данных, чем студийный talking head на простом фоне. Поэтому два ролика одинаковой длительности и разрешения при CRF 30 могут отличаться по размеру в несколько раз.

На размер также влияют preset, tune, film grain, GOP, temporal filtering, AQ и screen-content инструменты. Даже если CRF число не меняется, другой preset может выбирать менее эффективные режимы ради скорости. Отсюда следует практическое правило: нельзя рассчитывать место на диске формулой минуты × средний размер файла из прошлого проекта без запаса.

Если размер должен быть предсказуем, переходят к VBR и вычисляют target bitrate из длительности. Если требуется качество, принимают вариативный размер CRF. Компромисс CRF с maximum bitrate ограничивает пики, но всё равно не гарантирует точный конечный объём.

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

Как распознавать артефакты и связывать их с настройками

Блочность на плоских областях чаще указывает на недостаточный битовый бюджет или особенности loop filtering. Потеря мелкой текстуры при сохранении гладких контуров может быть связана с высоким CRF, быстрым preset, temporal filtering или выбранной психовизуальной целью. Дыхание качества во времени может указывать на распределение QP между temporal layers или rate-control давление.

Полосы на градиентах требуют отдельно проверить bit depth. Если источник прошёл 8-битное преобразование до SVT-AV1, повышение качества кодера не восстановит утраченные уровни. Цветные контуры вокруг текста часто связаны с 4:2:0 и цветовым ресэмплингом. Дёргание при воспроизведении может быть вообще не артефактом кодирования, а ошибкой timestamps или слишком тяжёлым для устройства битстримом.

При зерне артефакт может выглядеть как пластик после временной фильтрации или как чрезмерно регулярный синтезированный noise. Здесь тестируют связку temporal filtering, film grain и denoise, а не только CRF. В тёмных сценах дополнительно полезно проверить luminance QP bias.

Хорошая диагностика всегда начинается с минимального изменения. Если одновременно понизить CRF, сменить tune, отключить CDEF и включить variance boost, улучшение нельзя приписать конкретной причине. Один параметр — один A/B тест.

Совместимость воспроизведения и --fast-decode

AV1-декодеры заметно различаются по мощности и набору оптимизаций. Поток, который легко проигрывается на настольном CPU, может перегружать старую приставку или мобильное устройство. --fast-decode позволяет сдвинуть решения кодировщика в сторону более простого декодирования. Уровень 2 сильнее ориентирован на скорость декодера, чем уровень 1.

Эта опция не заменяет требования profile/level и не обеспечивает наличие аппаратного AV1. Если устройство вообще не поддерживает нужную глубину или AV1-кодек, поток не станет совместимым от fast-decode. Зато для устройств с поддержкой AV1, но ограниченным запасом вычислений, такой профиль может уменьшить риск пропусков кадров.

Совместимость проверяют на реальном целевом устройстве. Синтетический benchmark декодера полезен, но плеер одновременно занимается demux, audio, subtitles, scaling и rendering. 4K60 HDR создаёт совсем другую нагрузку, чем 1080p24 SDR.

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

Автоматизация через exit code и журнал ошибок

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

--errlog позволяет отделить ошибки SVT-AV1 от обычного прогресса. В сложной цепочке FFmpeg → SvtAv1EncApp → mux каждому процессу желательно иметь свой stderr. Тогда broken pipe можно связать с первой реальной ошибкой, а не с последним следствием.

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

После аварийного прерывания двухпроходного VBR временный stats-файл может остаться частично записанным. Повторный второй проход на таком файле запрещён логикой самого процесса: сначала заново получают корректную статистику первого прохода или запускают полный --passes 2 workflow.

Когда имеет смысл прямой SvtAv1EncApp, а когда FFmpeg

Прямой запуск удобен, когда вход уже Y4M/YUV, нужен максимально прозрачный доступ к параметрам, проводятся codec benchmarks или разрабатывается собственная интеграция. В такой схеме легко видеть, какие значения понимает сама библиотека, и минимизировать влияние контейнера и декодера на эксперимент.

FFmpeg удобнее для повседневных файлов: он открывает десятки контейнеров, выбирает дорожки, делает resize/crop, конвертирует pixel format, копирует audio и формирует конечный MKV/MP4. Это снижает количество временных файлов и делает pipeline компактнее. Цена — дополнительный слой опций, где часть параметров имеет имена FFmpeg, а часть передаётся через -svtav1-params.

Для отладки полезно уметь переходить между двумя подходами. Если FFmpeg-команда выдаёт странный результат, проблемный отрезок можно вывести в Y4M и повторить кодирование непосредственно SvtAv1EncApp. Если прямое приложение работает, ошибка вероятнее находится в фильтрах, wrapper или mux. Если воспроизводится и там, проблема ближе к параметрам SVT-AV1 или входным кадрам.

Такое разделение обязанностей помогает не приписывать SVT-AV1 функции, которых у него нет. Кодировщик отвечает за AV1-видео; чтение произвольных медиаконтейнеров, монтаж и звук находятся снаружи.

Резервное копирование профиля кодирования

Для долгосрочного проекта недостаточно сохранить только конечный файл. Минимальный набор воспроизводимости включает команду, cfg, версию SvtAv1EncApp, версию библиотеки, параметры предварительного FFmpeg-фильтра и сведения об исходном pixel format. Если применялись HDR metadata или ROI-карты, сохраняют и их источники.

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

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

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

Как подобрать параметры без чужих магических пресетов

Готовая строка из форума может быть полезна как перечень идей, но не как универсальный профиль. У другого автора могли быть иной исходник, другая библиотека, форк с дополнительными ключами, другая цель по размеру и другой декодер. Надёжнее начать с малого числа параметров: вход, выход, preset, CRF либо VBR/CBR, bit depth и при необходимости цветовые метаданные. Такой базовый encode становится контрольной точкой, относительно которой виден эффект каждого следующего изменения.

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

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

Тонкие параметры добавляют только после появления конкретной проблемы. Если зерно потеряло характер — тестируют film grain и temporal filtering. Если запись экрана размывает буквы — проверяют RGB→YUV420 и SCM. Если слабый клиент не успевает декодировать — рассматривают fast-decode и более подходящую структуру. Если тёмные сцены деградируют сильнее светлых — изучают luminance QP bias. Так каждая опция имеет проверяемую причину появления в команде.

Отдельно следует различать throughput и latency. Для офлайн-архива важна суммарная скорость обработки часов материала, поэтому несколько экземпляров могут быть выгодны. Для RTC важнее время отдельного кадра и отсутствие длинной очереди, поэтому параметры random access, lookahead и глубокого параллелизма оцениваются иначе. Один быстрый профиль не оптимален одновременно для обоих сценариев.

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

Минимальная валидация перед массовым запуском

Перед очередью из сотен файлов выполняют три коротких задания. Первое — простой SDR 8-bit фрагмент; он подтверждает базовую работоспособность приложения и mux. Второе — 10-bit материал, чтобы проверить глубину и pixel format. Третье — самый сложный тип контента из будущей очереди: HDR, screen content, высокий fps или 4K. Такой набор выявляет ошибки конфигурации дешевле, чем первый неудачный многочасовой encode.

У каждого результата автоматически сверяют код возврата, размер больше нуля, декодирование нескольких кадров, длительность, разрешение и bit depth. Для HDR дополнительно проверяют цветовые поля. Если используется VBR, сравнивают фактический средний bitrate с целевым. Если CBR/RTC — анализируют не только среднее, но и поведение по времени. При двух проходах убеждаются, что файл статистики создан текущим первым проходом.

Затем проверяют имена и пути. В пакетных сценариях особенно опасны совпадающие имена output.ivf, svtav1_2pass.log и временные Y4M. Два параллельных задания не должны писать в один и тот же ресурс. Временный каталог лучше формировать из уникального идентификатора входа, а после успешного mux очищать.

Наконец, фиксируют свободное место и RAM. Даже если конечный AV1 мал, промежуточный reconstructed YUV или случайно включённый raw output способен занять сотни гигабайт. Высокий --lp на нескольких 4K заданиях может исчерпать память задолго до диска. Предварительная проверка ресурсов — часть корректной настройки кодировщика, а не административная мелочь.

Сравнение SVT-AV1 с аналогами

Программа	Лучше подходит для	Главное ограничение
SVT-AV1	CPU-кодирования AV1 с широким диапазоном пресетов, VOD и low-delay сценариев	Консольный интерфейс и вход YUV/Y4M у SvtAv1EncApp
libaom-av1	Эталонной реализации AV1, исследований и тонкой настройки программного кодирования	На медленных режимах очень высока вычислительная стоимость
rav1e	Программного AV1-кодирования и интеграций, где удобна реализация на Rust	Другой набор пресетов и параметров, команды SVT-AV1 не переносимы напрямую
NVEncC с AV1 NVENC	Очень быстрого AV1-кодирования на совместимых видеокартах NVIDIA	Требуется поддерживаемый аппаратный AV1-энкодер NVIDIA
QSVEncC с AV1 Quick Sync	Быстрого аппаратного AV1-кодирования на совместимой графике Intel	Доступность AV1 зависит от конкретного поколения Intel GPU

Практический выбор определяется не названием кодека в строке вывода, а ограничениями pipeline. SVT-AV1 подходит, когда нужен программный CPU-кодировщик с детальным управлением и воспроизводимой работой на разных системах. libaom полезен как другой программный ориентир, rav1e — как независимая реализация, а NVEncC/QSVEncC меняют класс задачи в сторону аппаратной скорости. Сравнивать их корректно при одинаковом исходнике, разрешении, целевой совместимости и сопоставимом качестве или битрейте; одинаковые номера preset/CRF между кодировщиками значения не имеют.

Частые вопросы о SVT-AV1

Можно ли открыть MP4 прямо в SvtAv1EncApp?

Нет как обычный контейнер с декодированием. Приложение принимает Y4M/YUV или поток через stdin. Для MP4 удобнее FFmpeg с libsvtav1 либо FFmpeg, который декодирует MP4 и передаёт Y4M по pipe.

Можно ли получить MKV одной командой SvtAv1EncApp?

Само приложение создаёт AV1 в IVF или raw OBU. MKV, MP4 и другие пользовательские контейнеры формирует внешний мультиплексор. FFmpeg с libsvtav1 может выполнить кодирование и mux в одной командной цепочке.

Какой preset самый качественный?

Меньший номер использует более дорогие поиски и обычно даёт лучшую эффективность сжатия, но preset не является самостоятельной шкалой конечного качества. Итог также определяют CRF/bitrate, tune, источник и другие параметры. Выбирают самый медленный preset, который оправдан доступным временем, а затем подбирают качество.

Что лучше: CRF или VBR?

CRF удобен, когда важнее устойчивое качество и нет строгого размера. VBR нужен, когда средний битрейт или объём заранее ограничен; при жёстком бюджете полезны два прохода. CBR имеет смысл для real-time и каналов с более строгой временной пропускной способностью.

Зачем 10 бит для SDR?

10-битный pipeline даёт больше уровней представления и может уменьшить полосы на градиентах. Но он не создаёт новую информацию из уже испорченного 8-битного источника. Важно, чтобы вся цепочка — конвертация, pipe, --input-depth и декодер — согласованно поддерживала 10 бит.

Можно ли кодировать 4:4:4?

Текущая таблица параметров перечисляет несколько color-format значений, но отдельно отмечает, что поддерживается YUV420. Поэтому для этой программы не следует строить 4:4:4 workflow только по наличию числового пункта в справке.

Нужно ли включать film grain для любого шумного видео?

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

Почему команда из интернета не работает?

Она могла быть написана для другой версии, для FFmpeg или для модифицированного форка. Проверяют SvtAv1EncApp --help и --version, затем оставляют минимальную команду и добавляют спорные ключи по одному.

Контрольный рабочий порядок

1. Проверить --version и --help, чтобы точно знать набор параметров установленного бинарного файла.
2. Подготовить Y4M/YUV нужной глубины либо выбрать интеграцию FFmpeg libsvtav1.
3. Зафиксировать разрешение, fps, bit depth и цветовые метаданные до подбора качества.
4. Выбрать preset по реальному временному бюджету и один режим rate control: CRF, VBR или CBR.
5. На коротких репрезентативных фрагментах подобрать качество, не смешивая сразу множество тонких флагов.
6. При необходимости настроить GOP, film grain, screen content, parallelism и ограничения потока.
7. Выполнить полный encode, сохранив лог, команду и статистику.
8. Собрать конечный контейнер без повторного кодирования видео и проверить длительность, декодирование и метаданные.

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