VCEEncC позволяет перекодировать видео с использованием аппаратных кодировщиков AMD VCE/VCN, выбирать H.264/AVC, HEVC или AV1, управлять режимом битрейта и структурой потока, выполнять аппаратное декодирование, фильтрацию, изменение размера, обработку HDR, звука, субтитров и метаданных, а затем сохранять результат в подходящий контейнер или передавать его по конвейеру.

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

При работе важно разделять возможности VCEEncC и возможности самого аппаратного блока AMD. Наличие параметра в командной строке не означает, что любой Radeon поддержит его одинаково: доступность AV1, 10-битного HEVC, B-кадров, предварительного анализа, отдельных профилей и других функций зависит от поколения VCE/VCN и драйвера. Поэтому практическая настройка начинается с диагностики оборудования, а затем уже переходит к выбору режима кодирования и фильтров.

Для каких задач нужен VCEEncC

VCEEncC рационально использовать там, где требуется аппаратное перекодирование на AMD без потери контроля над параметрами. Это может быть подготовка H.264 для совместимых устройств, HEVC для более компактного хранения, AV1 на поддерживаемых GPU, пересжатие архивных записей, конвертация потоков после монтажа или автоматическая обработка больших каталогов. Командный интерфейс особенно удобен для пакетных сценариев: одну проверенную строку можно запускать из BAT-файла, PowerShell, shell-скрипта, менеджера очередей или другого фронтенда.

Второй тип задач — обработка видео до кодирования. В VCEEncC встроена крупная группа VPP-фильтров: изменение размера, деинтерлейс, inverse telecine, подавление шума, уменьшение бандинга, коррекция цвета, резкость, удаление ореолов, субтитры, удаление логотипов и ряд более специализированных операций. Это позволяет не передавать каждый промежуточный кадр во внешнюю программу, если нужная обработка уже есть в самом VCEEncC.

Третий сценарий — роль одного узла в сложном конвейере. Программа принимает Y4M, raw-видео, AviSynth и VapourSynth, умеет читать обычные медиафайлы через библиотеки FFmpeg, а также работать со стандартным вводом и выводом. Поэтому VCEEncC можно поставить между декодером и мультиплексором, использовать как аппаратный кодировщик после кадрового сервера либо, наоборот, применить только фильтры и вывести raw-поток в другую утилиту.

• Транскодирование: смена видеокодека, профиля, глубины цвета, разрешения и битрейта.
• Пакетная обработка: одинаковая схема кодирования для набора файлов и автоматизация через скрипты.
• Фильтрация: деинтерлейс, масштабирование, шумоподавление, HDR-to-SDR и другие VPP-операции.
• Ремультиплексирование: перенос аудио, субтитров, глав, вложений и метаданных вместе с новым видеопотоком.
• Диагностика: проверка доступных кодеков, аппаратных функций, OpenCL и возможностей конкретного GPU.

Как устроена командная строка

Базовый синтаксис строится вокруг входа, выхода и набора параметров между ними. Короткие ключи используются для самых частых действий: -i задаёт вход, -o — выход, -c или --codec выбирает видеокодек. Остальные опции уточняют режим декодирования, управление качеством, формат изображения, фильтры, дорожки и служебные параметры. Логика предсказуема: сначала стоит определить, каким способом читается источник, затем указать кодек и rate control, после чего добавлять фильтры и операции с контейнером.

VCEEncC64.exe -i "input.mp4" -o "output.mp4" --codec hevc --vbr 8000

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

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

Проверка видеокарты перед первым кодированием

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

VCEEncC64.exe --check-hw
VCEEncC64.exe --check-features 0
VCEEncC64.exe --check-clinfo

--check-features даёт более подробный отчёт: профили, глубины, ограничения по кадру и другие аппаратные возможности, которые VCEEncC смог получить через AMF. Именно этот вывод полезно сверять с ошибкой unsupported при попытке включить 10 бит, B-кадры, определённый профиль или режим предварительного анализа. --check-clinfo помогает понять состояние OpenCL, что особенно важно для части VPP-фильтров.

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

Команда	Что показывает	Когда применять
--check-hw	Доступность VCE/VCN и поддерживаемые видеокодеки	Перед первым запуском и после смены GPU/драйвера
--check-features	Подробные аппаратные возможности устройства	При ошибках профиля, глубины, B-кадров, PA
--check-clinfo	Информацию OpenCL	Если не запускаются OpenCL-фильтры
--check-encoders	Доступные энкодеры мультимедийной подсистемы	При выборе внешнего аудио/avcodec-кодека
--check-formats	Поддерживаемые контейнеры и форматы	Если выходной формат не определяется

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

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

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

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

Способы чтения входного видео

VCEEncC различает несколько входных путей. Обычные контейнеры можно читать через связку avformat и декодера; --avsw выбирает программное декодирование, а --avhw — аппаратное. Для кадровых серверов предусмотрены AviSynth и VapourSynth, для межпроцессного обмена — Y4M и raw, также поддерживается AVI. Если явный режим не задан, тип чтения обычно определяется по расширению и содержимому.

Режим	Назначение	Практическое замечание
--avhw	Аппаратное декодирование	Минимизирует CPU-нагрузку, но зависит от возможностей декодера GPU
--avsw	Программное декодирование	Полезно для несовместимого с HWDecode источника и сложных случаев
--avs	AviSynth	Подходит для готовых Avisynth-скриптов
--vpy / --vpy-mt	VapourSynth	Удобно для Python-пайплайнов обработки
--y4m	YUV4MPEG2	Хороший формат для pipe между видеопрограммами
--raw	Сырые кадры	Нужно явно задать геометрию и частоту кадров

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

Для AviSynth важна кодировка скрипта. VCEEncC ориентируется на UTF-8, а для старых сценариев в системной кодовой странице предусмотрен переключатель режима обработки кодировки. Если путь с кириллицей или комментарии в AVS неожиданно дают ошибку чтения, полезно сначала проверить кодировку файла, а не параметры кодировщика.

Аппаратное и программное декодирование

--avhw позволяет оставить декодирование на GPU и передавать кадры дальше по аппаратному пути. На подходящем источнике это снижает нагрузку на CPU и уменьшает объём ненужных копирований. Однако аппаратный декодер не универсален: перечень кодеков и поддерживаемых профилей определяется поколением GPU. Наличие аппаратного кодирования HEVC, например, не гарантирует аппаратное декодирование любого HEVC-потока.

--avsw использует программный декодер и часто оказывается лучшим выбором для нестандартных файлов, старых кодеков, повреждённых потоков или ситуаций, где HW-декодер даёт ошибку на смене разрешения. Это не означает, что само кодирование становится программным: кадры после декодирования всё равно могут передаваться аппаратному VCE/VCN.

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

Кодеки H.264, HEVC и AV1

Основные аппаратные видеокодеки выбираются через --codec h264, --codec hevc и --codec av1. H.264 остаётся самым совместимым вариантом для старых устройств и сервисов. HEVC позволяет эффективнее расходовать битрейт и имеет развитую поддержку 10-битного видео и HDR на подходящем железе. AV1 предназначен для более новых поколений VCN и требует аппаратной поддержки именно AV1-кодирования.

Нельзя переносить один и тот же набор параметров между кодеками механически. Например, часть режимов rate control доступна только для определённых кодеков, набор профилей различается, а AV1 имеет собственные параметры CDEF, тайлов, screen content tools и обновления CDF. Если ключ существует в общей документации, это ещё не означает, что он применим к текущему --codec.

Отдельный вариант -c raw выводит необжатые кадры после обработки. Он полезен, когда VCEEncC используют только как VPP-движок: например, деинтерлейс и цветокоррекция выполняются здесь, а последующее кодирование делает другой энкодер. Также предусмотрен путь через avcodec-энкодеры, но их параметры задаются отдельным механизмом и не используют обычные настройки аппаратного VCE/VCN.

H.264/AVC: совместимость и настройка

Для H.264 чаще всего выбирают профиль High, подходящий уровень и один из режимов CQP, VBR, CBR или доступных высококачественных вариантов rate control. На старых Radeon H.264 обычно обладает наиболее широкой аппаратной поддержкой, поэтому этот кодек удобен как базовая проверка тракта: если даже H.264 не запускается, сначала следует разбираться с драйвером, AMF и выбором устройства.

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

Параметры B-кадров, количества ссылочных кадров и оценки движения следует менять только после проверки отчёта --check-features. Некоторые поколения AMD имеют ограничения, которые отличаются от NVENC или программного x264. Ошибка unsupported здесь чаще означает аппаратное ограничение, а не ошибочный синтаксис.

HEVC: 10 бит, профиль и высокий динамический диапазон

HEVC полезен для хранения 4K, 10-битного материала и HDR, но набор возможностей заметно зависит от поколения VCN. Для 10-битного вывода используется --output-depth 10, а при необходимости выбирается профиль Main 10. Если аппаратный кодировщик не принимает P010 или соответствующую глубину, VCEEncC сообщит об этом ещё на этапе инициализации. Попытка заставить неподдерживаемый GPU параметром профиля не помогает.

Для HEVC особенно важно правильно перенести цветовые характеристики. Если исходник HDR10, недостаточно просто выбрать 10 бит: в выходном потоке должны оставаться корректными primaries, transfer, matrix, mastering display и content light level, если они присутствуют и нужны конечному устройству. VCEEncC умеет копировать или явно задавать эти значения, поэтому потери HDR-метаданных можно избежать без ручного ремультиплексирования.

У HEVC есть параметр tier наряду с level. Tier связан прежде всего с предельным битрейтом в рамках уровня. Для обычной домашней библиотеки High tier требуется не всегда; его имеет смысл включать только если фактические ограничения потока выходят за Main tier и целевые декодеры это поддерживают.

AV1: требования к железу и специфические параметры

AV1-кодирование доступно только на тех AMD GPU, где соответствующий аппаратный блок присутствует. Поэтому первый шаг — не поиск правильного ключа, а --check-hw. Если AV1 отсутствует в списке поддерживаемых кодеков, программными параметрами VCEEncC его аппаратное кодирование добавить нельзя.

Помимо общих настроек качества AV1 имеет собственные опции: число тайлов, CDEF, screen content tools, управление CDF, temporal layers и режим адаптивной квантизации. Эти параметры стоит рассматривать как тонкую настройку конкретного аппаратного энкодера. Например, screen-content tools уместны для записи интерфейсов, презентаций и другого материала с резкими границами и плоскими областями, но не обязательно дают выигрыш на обычном кино.

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

Режимы управления качеством и битрейтом

VCEEncC предлагает несколько принципиально разных способов управлять объёмом данных. CQP фиксирует значения квантования для типов кадров и поэтому удобен, когда важнее постоянная степень квантования, а размер файла вторичен. CBR стремится к постоянному битрейту и нужен в каналах с жёсткой полосой. VBR допускает изменение мгновенного расхода данных вокруг целевого значения. QVBR ориентирован на качество с переменным битрейтом и на поддерживаемом железе даёт другой баланс.

Высококачественные варианты CBR-HQ и VBR-HQ доступны не во всех сочетаниях кодека и GPU. Если режим присутствует в документации, но отсутствует в аппаратных возможностях, VCEEncC не может эмулировать его программно в рамках VCE/VCN. Поэтому таблицу поддерживаемых функций конкретного адаптера нужно считать первичным источником.

Режим	Когда применять	Что контролирует пользователь
CQP	Когда размер вторичен и нужна заданная квантизация	QP для типов кадров
CBR	Стриминг и фиксированная полоса	Целевой битрейт
CBR-HQ	CBR с доступными улучшениями качества	Целевой битрейт и аппаратные ограничения
VBR	Файлы и потоки с переменной сложностью сцен	Средний/целевой битрейт
VBR-HQ	VBR с высококачественным режимом на поддерживаемом GPU	Битрейт и дополнительные ограничения
QVBR	Ориентация на визуальное качество при переменном расходе	Параметр качества и связанные лимиты

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

Preset и аппаратные режимы качества

--preset или короткий ключ -u управляет аппаратным компромиссом между скоростью и качеством. Доступные значения зависят от кодека и поколения AMF. Более медленный режим обычно включает дополнительные внутренние процедуры анализа или менее агрессивные упрощения, но фактическая разница определяется аппаратным энкодером.

У аппаратного кодирования preset не равен пресету x264/x265. Нельзя ожидать, что переход на slow превратит VCE/VCN в программный энкодер по качеству или использует те же алгоритмы. Это всего лишь способ выбрать одну из конфигураций, которые предоставляет AMF. Если требуется максимальное качество на бит, полезно сравнивать несколько режимов на типичных для своей библиотеки материалах.

В пакетной обработке preset лучше фиксировать явно. Тогда изменение внешнего окружения или автоматического выбора не приведёт к неожиданной смене баланса скорость/качество. Для повторяемости также стоит явно задавать rate control, максимальный битрейт и критичные параметры GOP.

GOP, B-кадры, ссылки и LTR

--gop-len определяет максимальную длину GOP. Длинный GOP обычно повышает эффективность сжатия, но увеличивает расстояние между ключевыми кадрами и может ухудшить удобство перемотки или работу сегментации. Для монтажа, интерактивного поиска и потоковой раздачи могут быть нужны более частые ключевые кадры; для архивного файла допустим более длинный GOP.

--bframes включает B-кадры там, где аппаратный энкодер их поддерживает. Параметры B-pyramid, delta QP и адаптивного minigop дают дополнительный контроль в поддерживаемых кодеках. Однако значение 3 B-кадра нельзя считать универсально лучшим: поддержка и реальное поведение VCE/VCN меняются по поколениям, а низкая задержка часто требует уменьшить или отключить B-кадры.

--ref задаёт количество ссылочных кадров, --ltr — long-term reference для H.264/HEVC на поддерживаемом оборудовании. Увеличение этих чисел не гарантирует улучшения и может выйти за аппаратный лимит. Если после изменения появляется device operation failure, следует вернуться к значениям из отчёта возможностей, а не искать ошибку в контейнере.

Точность оценки движения для H.264/HEVC выбирается через --motion-est: auto, quarter-pel, half-pel или full-pel. Более точная оценка потенциально помогает компрессии, но доступность и скорость зависят от аппаратной реализации. Обычно auto — хорошая отправная точка, если нет конкретной причины фиксировать режим.

Ограничение битрейта, VBV и совместимость потока

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

--enforce-hrd ориентирует поток на требования HRD, --filler может дополнять поток служебными данными для поддержания номинального битрейта. --aud вставляет access unit delimiter, а --repeat-headers повторяет наборы параметров. Последний параметр особенно полезен в потоковых и сегментированных сценариях; при некоторых HDR-настройках повтор заголовков включается автоматически.

Для обычного MP4 или MKV лишние ограничения лучше не добавлять без необходимости. Цель — не максимальное количество включённых опций, а соответствие целевому декодеру. Если файл предназначен для конкретной приставки, телевизора или видеосервера, нужно ориентироваться на его поддерживаемые profile/level/tier и пределы VBV.

Глубина цвета, профиль, уровень и tier

--output-depth выбирает битовую глубину выхода там, где это допускает кодек и GPU. Для HEVC и AV1 10 бит часто используют не только ради HDR, но и для уменьшения видимого бандинга после фильтрации. При этом 10-битный выход сам по себе не создаёт дополнительную информацию, если источник был 8-битным; он лишь меняет формат дальнейшего представления и квантования.

--profile и --level задают ограничения стандарта, а для HEVC дополнительно используется --tier. Автоматический режим удобен, но в совместимых цепочках бывает полезно зафиксировать профиль. Например, Main 10 нужен для 10-битного HEVC, а слишком высокий level может сделать поток формально несовместимым со старым декодером, даже если разрешение само по себе ему знакомо.

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

SAR, DAR и геометрия кадра

VCEEncC умеет задавать sample aspect ratio и display aspect ratio. Это особенно важно для старых источников с не квадратными пикселями: изменение разрешения без корректировки SAR может визуально растянуть или сжать изображение. Для современных квадратных пикселей обычно сохраняют SAR 1:1, но архивные DVD/TV-материалы требуют внимательности.

--crop обрезает края, а --output-res задаёт итоговую геометрию. В режиме изменения размера можно учитывать исходное соотношение сторон, чтобы не рассчитывать второе измерение вручную. Однако после crop исходная геометрия уже другая, поэтому порядок действий нужно понимать: сначала удаляются ненужные области, затем рассчитывается целевое масштабирование.

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

Цветовой диапазон и сигнальные характеристики

Параметры --colorrange, --colormatrix, --colorprim, --transfer и --chromaloc управляют тем, как цвет описан в видеопотоке. Они не являются декоративными тегами: неверная матрица или диапазон может привести к поднятому чёрному, клиппингу белого, сдвигу цветов или неправильной обработке HDR на следующем этапе.

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

Особую осторожность нужно проявлять при переходе между BT.601, BT.709 и BT.2020. Простая смена тега не равна реальному преобразованию пикселей. Если требуется именно конвертация цветового пространства, используют VPP color conversion, а выходные сигнальные поля выставляют в соответствии с фактическим результатом.

HDR10: mastering display и MaxCLL

Для HEVC и AV1 VCEEncC может переносить или задавать статические HDR-метаданные: mastering display и Maximum Content Light Level / Maximum Frame-Average Light Level. Эти данные важны для корректного tone mapping на телевизоре или плеере, но имеют смысл только вместе с подходящими primaries и transfer, обычно BT.2020 и PQ для HDR10.

Если источник уже содержит корректные значения, режим copy уменьшает риск ручной ошибки. При перекодировании, которое существенно меняет яркость или выполняет HDR-to-SDR, копирование исходных HDR-метаданных может быть неверным: они будут описывать уже не тот сигнал. После tone mapping в SDR следует выставлять SDR-характеристики и не тащить статические HDR поля только потому, что они были в исходнике.

Параметр repeat headers связан с тем, как служебные данные присутствуют в elementary stream. При включённых HDR-метаданных VCEEncC может активировать повтор нужных заголовков автоматически, что полезно при последующей сегментации или потоковом использовании.

HDR10+ и динамические метаданные

Динамические HDR10+ данные могут передаваться через файл метаданных или копироваться из поддерживаемого источника с помощью соответствующих опций. В отличие от статического mastering display, такие данные меняются по сценам или кадрам, поэтому их привязка к временной структуре видео должна оставаться корректной.

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

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

Dolby Vision RPU

VCEEncC поддерживает передачу Dolby Vision RPU для HEVC и AV1 в предусмотренных режимах. RPU можно читать из внешнего файла или копировать из входного потока, если структура материала и используемый профиль допускают такой сценарий. Также есть параметры для коррекции active area offsets, что важно при изменении области изображения.

Dolby Vision нельзя сводить к одному флагу. Профиль определяет требования к базовому слою, служебным NAL/OBU, заголовкам и другим свойствам. VCEEncC умеет автоматически включать некоторые обязательные параметры для выбранного профиля, но это не отменяет проверки совместимости контейнера, целевого устройства и самой последовательности RPU.

При кропе чёрных полей следует понимать, соответствуют ли RPU-координаты новой активной области. Параметр crop для RPU может обнулить active area offsets, но применять его стоит только если это соответствует фактическому изображению. Неверная обработка динамических данных сложнее заметна на глаз, чем обычная ошибка разрешения.

Масштабирование изображения

VCEEncC имеет несколько путей масштабирования: аппаратные алгоритмы AMF и набор VPP-ресайзеров, включая классические фильтры и варианты на базе libplacebo. Выбор зависит от задачи. Для простого уменьшения до распространённого разрешения часто достаточно стандартного качественного алгоритма; для сложной апскейл-цепочки могут понадобиться фильтры с настраиваемым ядром или шейдер.

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

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

Деинтерлейс: AFS, NNEDI, BWDIF и другие варианты

Для межстрочного видео VCEEncC предоставляет несколько VPP-фильтров. --vpp-bwdif умеет выдавать кадры с исходной частотой или bob с удвоенной частотой. Поле может определяться автоматически либо фиксироваться как TFF/BFF. Это простой и понятный вариант для типичных interlaced-источников.

Для более сложных задач есть AFS, NNEDI, decomb, IVTC, KFM и RTGMC-подобные цепочки. Они отличаются не только качеством, но и назначением. IVTC применим к телесин-паттернам, а обычный deinterlace нужен для настоящего межстрочного движения. Попытка обработать telecine как обычный bob-деинтерлейс создаёт другой временной результат и лишние кадры.

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

Тяжёлые деинтерлейс-фильтры могут стать главным ограничением скорости, даже если сам VCE/VCN кодирует намного быстрее реального времени. При оценке производительности нужно смотреть не только VE load, но и цепочку VPP целиком.

Удаление дублей, decimate и работа с частотой кадров

--vpp-decimate и --vpp-mpdecimate предназначены для удаления похожих или повторяющихся кадров по заданным критериям. --vpp-select-every позволяет выбирать кадры с регулярным шагом. Эти фильтры меняют временную структуру, поэтому их нельзя воспринимать как обычную косметическую обработку.

После удаления кадров критично корректно вести timestamps. Если просто выкинуть кадры без соответствующей временной модели, видео ускорится или разойдётся со звуком. VCEEncC имеет режимы avsync, timecode и passthrough временных меток, которые позволяют сохранить нужную временную семантику в зависимости от источника.

Для материала с repeat field flags или переменной частотой кадров лучше сначала определить, что требуется получить: CFR для совместимости, VFR с сохранением исходных временных отметок или восстановленный прогрессивный поток после IVTC. От этой цели зависит и фильтр, и режим синхронизации.

Шумоподавление

В наборе VPP есть пространственные и пространственно-временные фильтры: KNN, NLMeans, PMD, HQDN3D, BM3D, FFT3D, convolution3d, smooth и другие. Разница между ними не косметическая. Пространственный фильтр анализирует область одного кадра, а временной использует соседние кадры и способен лучше сохранять статические детали, но рискует оставить хвосты на движении при слишком сильных настройках.

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

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

Устранение мерцания, зерна и локальных дефектов

Для источников с нестабильной яркостью доступен deflicker; для ореолов — dehalo и finedеhalo; для ринга — hqdering; для пространственной стабилизации предусмотрены отдельные фильтры. Такие инструменты полезны при восстановлении старых записей, но их следует применять после понимания дефекта. Например, dehalo не является универсальным sharpen и при отсутствии ореолов может только испортить края.

Часть фильтров имеет параметры порога, радиуса, силы и защиты деталей. Порог определяет, какие изменения считать дефектом, а сила — насколько агрессивно исправлять. Поэтому увеличение strength без настройки threshold часто даёт худший результат, чем умеренное значение с правильно выбранной маской.

Если после фильтрации кодирование стало резко медленнее, это не обязательно проблема VCE/VCN. Сложные VPP-фильтры могут занимать значительно больше времени, чем аппаратный энкодер. Для диагностики полезны встроенные performance monitor и OpenCL timeline, которые показывают узкий участок конвейера.

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

VCEEncC содержит unsharp, edgelevel, warpsharp, MSharpen, CAS и другие инструменты усиления деталей. Они действуют по-разному: unsharp повышает локальный контраст, edgelevel усиливает границы с порогом шума, MSharpen использует маску краёв, а CAS ориентирован на адаптивную резкость. В одной цепочке обычно не нужно одновременно включать несколько сильных sharpen-фильтров.

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

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

Дебандинг и дизеринг

Бандинг заметен на небе, тенях и плавных градиентах. Встроенный --vpp-deband ищет недостаточно плавные переходы и добавляет контролируемый dithering. Настраиваются диапазон анализа, пороги яркости и цветности, сила дизеринга и изменение случайной последовательности по кадрам.

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

Есть также вариант на базе libplacebo с параметрами iterations, radius, threshold и зерна для яркости/цветности. Он удобен в цепочках, где уже используется libplacebo для масштабирования или tone mapping. Выбор между реализациями лучше делать по конкретным градиентам, потому что характер остаточного шума у них различается.

Преобразование цвета и HDR-to-SDR

--vpp-colorspace выполняет реальное преобразование цветовых характеристик, а не просто переписывает теги. Через него можно переводить материал между матрицами и transfer-функциями, а также выполнять HDR-to-SDR. Для HDR2SDR важны параметры целевой яркости и пиков исходника: ошибочные значения дают либо серое, либо пересвеченное изображение.

Tone mapping должен учитывать назначение результата. SDR-файл обычно маркируют как BT.709 с подходящим transfer, а не сохраняют PQ/BT.2020 только потому, что это было во входе. После преобразования желательно проверить уровни чёрного, белого и насыщенные цвета на обычном SDR-дисплее.

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

Libplacebo, пользовательские шейдеры и продвинутая обработка

VCEEncC может использовать libplacebo для масштабирования, deband, tone mapping и пользовательских GLSL-шейдеров. В шейдер можно передавать compile-time значения через замену define и runtime-параметры, объявленные в формате libplacebo. Это позволяет встроить специализированную обработку без промежуточного рендера в другом приложении.

У пользовательского шейдера важно явно понимать рабочее цветовое пространство. VCEEncC позволяет выбирать входной CSP, цветовую систему и transfer, а также целевое разрешение. Шейдер, рассчитанный на линейный RGB, даст неверный результат, если применить его к нелинейному YUV без ожидаемого преобразования.

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

ONNX-фильтры, RIFE и модели

В VCEEncC присутствуют VPP-фильтры на базе ONNX Runtime и отдельный путь RIFE для интерполяции кадров. Модель задаётся именем из каталога моделей или прямым путём, а множитель кадров определяет целевую частоту. Это уже не обычный фиксированный фильтр: совместимость зависит от модели, доступного backend и объёма видеопамяти.

Интерполяция кадров полезна для повышения частоты движения, но создаёт синтетические кадры. На сценах с быстрыми перекрытиями, частицами, титрами и интерфейсными элементами возможны деформации. Поэтому результат нужно проверять визуально, особенно если исходник имеет монтажные склейки или variable frame rate.

ONNX-цепочки могут стать значительно тяжелее самого кодирования. Для длинных роликов имеет смысл сначала прогнать короткий фрагмент с типичными сценами и оценить память, скорость и артефакты. Если задача — только перекодирование, включение AI-фильтра на всякий случай не даёт преимуществ.

Субтитры: копирование и прожиг

Субтитры можно оставить отдельной дорожкой через copy или встроить в изображение VPP-фильтром subburn. Эти подходы решают разные задачи. Отдельная дорожка остаётся отключаемой и не требует повторного кодирования изображения при смене языка. Прожиг нужен для устройств без поддержки формата субтитров или для графики, которая должна быть всегда видна.

При копировании можно выбирать дорожки по номеру или языку, задавать кодек, disposition и metadata. Это полезно в MKV с несколькими языками: скрипт может переносить только нужные дорожки и сохранить пометки default/forced. Для сложных ASS/SSA важно убедиться, что контейнер и конечный плеер поддерживают их без преобразования.

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

Удаление логотипов и наложений

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

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

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

Поворот, отражение, padding и простые геометрические операции

VPP transform позволяет поворачивать и отражать кадр, а padding — добавлять поля. Это полезно при исправлении ориентации камеры, подготовке вертикального ролика к фиксированному canvas или выравнивании разрешения под требования энкодера. Добавленные поля становятся частью изображения, поэтому цвет фона и итоговое соотношение сторон следует выбирать осознанно.

Если задача состоит в сохранении исходного DAR при вписывании в другое разрешение, часто требуется комбинация resize и padding, а не растягивание до целевой ширины и высоты. В автоматизированном скрипте это предотвращает искажение роликов с разными соотношениями сторон.

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

Звук: копирование, перекодирование и выбор дорожек

VCEEncC работает не только с видеопотоком. --audio-copy переносит выбранные аудиодорожки без перекодирования, а --audio-codec позволяет назначить кодек. Дорожку можно выбирать по номеру или языку, отдельно задавать битрейт, качество, профиль, частоту дискретизации и другие параметры. Это удобно, когда видео нужно пересжать, а исходный звук уже подходит.

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

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

Аудиофильтры, задержка и извлечение

Через --audio-filter доступны аудиофильтры мультимедийной подсистемы: изменение громкости, задержка и другие операции. Параметр можно привязать к конкретной дорожке. Это полезно для мелких исправлений, когда нет смысла запускать отдельный FFmpeg только ради одного audio filter.

--audio-delay сдвигает аудио относительно видео, но применять его следует после понимания причины рассинхронизации. Если источнику нужен корректный timestamp handling, искусственная задержка лишь маскирует проблему. Для VFR/RFF-материала сначала проверяют режим avsync, временную базу и фактические PTS.

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

Главы, вложения, data streams и метаданные

При транскодировании контейнера легко потерять неочевидные элементы: chapters, fonts для ASS, обложки, data streams и пользовательские metadata. VCEEncC имеет отдельные опции копирования для глав, data и attachments, а также настройки метаданных видео, аудио, субтитров и файла в целом.

Для MKV с ASS-субтитрами вложенные шрифты особенно важны. Если перенести субтитры без attachments, внешний вид может измениться на системе, где нужного шрифта нет. Аналогично, chapter copy полезен для концертных записей и фильмов, где навигация по главам является частью структуры файла.

Метаданные можно копировать, очищать или задавать явно. В автоматическом архивном сценарии разумно копировать исходные title/language/disposition, но в публикационном пайплайне иногда полезнее удалить служебные поля и записать только нормализованные значения.

Обрезка по времени, seek и trim

--trim задаёт диапазоны кадров, а --seek и --seekto работают со временем. Это разные уровни управления: trim удобен, когда сценарий привязан к номерам кадров, а seek — когда нужно быстро вырезать временной фрагмент. Для точной резки вокруг keyframe аппаратный декодер может сначала переместиться к ближайшей доступной точке и декодировать до требуемой позиции.

При использовании trim вместе с VFR или force-CFR важно учитывать ограничения режима синхронизации. Некоторые комбинации намеренно запрещены, потому что одновременное изменение набора кадров и принудительное выравнивание временной шкалы создаёт неоднозначность. Если задача сложная, лучше сначала определить правильную временную модель, а затем задавать диапазоны.

Главы при trim можно либо подрезать вместе с видео, либо оставить без коррекции специальной опцией. Выбор зависит от того, сохраняется ли смысл временных меток после обрезки. Для клипа, вырезанного из середины фильма, некорректные исходные chapter timestamps обычно бесполезны.

VFR, CFR, временные метки и синхронизация

--avsync auto оставляет программе выбор нормального режима. forcecfr при необходимости дублирует или удаляет кадры, чтобы получить постоянную частоту и удержать синхронизацию со звуком. vfr передаёт исходные timestamps дальше и применяется при чтении через avsw/avhw. Для VFR-источника это часто корректнее, чем искусственно приводить всё к CFR.

--timestamp-passthrough сохраняет исходные временные метки и автоматически ориентирует синхронизацию на VFR. Есть также вывод timecode-файла и чтение внешнего timecode. Это полезно в цепочках, где кадровый сервер и контейнер должны точно согласовать нестандартную временную шкалу.

Если звук постепенно уплывает, нужно отличать постоянный сдвиг от накопительной ошибки. Постоянный сдвиг можно компенсировать delay, а накопительная ошибка обычно указывает на неправильную частоту кадров, timebase, RFF/VFR обработку или потерянные PTS. Исправлять её фиксированной задержкой бессмысленно.

Работа через pipe

VCEEncC умеет читать со стандартного ввода и писать в стандартный вывод. Это позволяет соединять инструменты без промежуточного огромного файла. Один из типичных вариантов — FFmpeg декодирует нестандартный источник в Y4M, VCEEncC кодирует кадры, а другой процесс принимает готовый поток или контейнер.

ffmpeg -i "input.mov" -an -pix_fmt yuv420p -f yuv4mpegpipe - | VCEEncC64.exe --y4m -i - --codec hevc -o "output.hevc"

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

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

AviSynth и VapourSynth в цепочке

AviSynth и VapourSynth позволяют вынести сложную обработку в скрипт, а VCEEncC оставить в роли аппаратного энкодера. Это удобно, если используются фильтры, которых нет во встроенном VPP, или нужен точный кадр-за-кадром pipeline. VCEEncC может читать такие скрипты напрямую, без обязательного промежуточного файла.

При VapourSynth важно корректно настроить окружение Python и плагины; при AviSynth — разрядность и кодировку. Ошибка загрузки скрипта не связана с VCE/VCN, поэтому диагностику лучше начинать с того, что сам frameserver открывает скрипт и выдаёт кадры. После этого подключать VCEEncC намного проще.

Если скрипт сам выполняет resize, colorspace и deinterlace, не следует случайно дублировать те же операции во встроенном VPP. Двойное преобразование цвета или два последовательных sharpen-фильтра — распространённая причина ухудшения изображения в длинных командных строках.

Мультиплексирование в MP4, MKV и другие контейнеры

Расширение выходного файла обычно позволяет определить контейнер автоматически, а --output-format задаёт его явно. В контейнер VCEEncC может одновременно положить новое видео, скопированный или перекодированный звук, субтитры, главы, данные и вложения. Это избавляет от отдельного remux в большинстве типичных сценариев.

Однако контейнер не принимает произвольные сочетания потоков. Например, некоторые аудиокодеки, виды субтитров или служебные данные удобнее хранить в MKV, чем в MP4. Если muxer отказывается записывать дорожку, сначала нужно проверить совместимость контейнера и codec tag, а не менять настройки VCE/VCN.

Для elementary stream можно вывести raw H.264/HEVC/AV1 без контейнера. Это полезно, когда последующее приложение само занимается мультиплексированием или требуется специализированный транспортный поток. В таком случае метаданные, главы и звук должны быть обработаны отдельно.

Сохранение максимума данных из исходного контейнера

Для архивного транскодирования часто требуется заменить только видео, а всё остальное сохранить. В VCEEncC для этого комбинируют копирование аудио, субтитров, data, attachments и chapters с копированием video/audio/subtitle/global metadata. HDR-метаданные и Dolby Vision также обрабатываются отдельными параметрами, потому что это не обычные теги контейнера.

Такую команду лучше сначала протестировать на файле с максимально сложной структурой: несколькими аудиодорожками, ASS с шрифтами, главами и HDR. Если тестировать только простой MP4 с одним AAC, легко пропустить потерю вложений или языка на реальных архивных MKV.

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

Предварительный анализ и адаптивные инструменты

Pre-analysis включается через группу параметров --pa. В зависимости от аппаратной поддержки можно настраивать lookahead, анализ сцен, spatial/temporal AQ, LTR и качество оценки движения. Этот блок способен улучшить распределение битрейта, но одновременно увеличивает вычислительную работу и предъявляет дополнительные требования к AMF.

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

Если PA вызывает device operation failure, следует сверить поддерживаемые возможности и упростить набор подпараметров. Особенно осторожно нужно сочетать LTR, B-кадры и AV1-функции на новом железе: они могут иметь поколенческие ограничения, которые не очевидны из названия параметра.

Оценка качества: SSIM, PSNR и VMAF

--ssim и --psnr позволяют посчитать метрики между обработанным исходным изображением и декодированным результатом. Это удобно для сравнения режимов на одном и том же материале, но метрика не заменяет визуальную оценку. Высокий PSNR не гарантирует субъективно лучший текстурный рисунок, а SSIM по-разному реагирует на шумоподавление.

VMAF можно вычислять через CPU при наличии соответствующей поддержки и runtime-библиотеки. Поскольку расчёт тяжёлый, скорость кодирования падает и нагрузка CPU растёт. Для массовой очереди разумнее сначала закодировать набор коротких тестов, сравнить VMAF/SSIM и только после выбора настроек запускать основной пакет без постоянного подсчёта метрик.

Метрики корректны только при сопоставимых кадрах. Если один вариант применяет frame interpolation, decimate, crop или другую временную/геометрическую операцию, прямое сравнение может требовать дополнительного выравнивания. Нельзя интерпретировать число без понимания, какие изображения фактически сравниваются.

Логи и мониторинг производительности

VCEEncC выводит подробную сводку выбранной конфигурации перед кодированием: GPU, AMF, вход, выходной кодек, разрешение, частоту кадров, rate control, GOP, ссылочные кадры, VPP и структуру mux. Эта сводка полезнее самой командной строки, потому что показывает не только то, что было запрошено, но и то, во что параметры реально разрешились.

В финальной статистике видны скорость, размер, средний битрейт, время и загрузка подсистем. Если VE загружен полностью, а скорость низкая, узким местом, вероятно, является сам аппаратный энкодер. Если VE простаивает, нужно смотреть декодер, CPU, VPP, disk I/O и передачу кадров.

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

Параллельное кодирование и несколько заданий

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

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

На системе с несколькими GPU наиболее предсказуемый вариант — явно распределить задачи по --device. Тогда очередь не зависит от мгновенной оценки загрузки. Для длинных автоматических работ также стоит ограничить число одновременных процессов, чтобы не вытеснить VPP из видеопамяти.

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

Для live и near-live задач важны не только fps, но и задержка от входного кадра до готового потока. Lookahead, B-кадры, буферизация и некоторые VPP увеличивают latency. Поэтому профиль низкой задержки обычно строится из более короткой цепочки, минимального необходимого анализа и подходящей структуры GOP.

CBR с корректным VBV чаще подходит сетевому каналу, чем CQP, потому что позволяет планировать пропускную способность. Однако слишком маленький buffer и жёсткий max bitrate ухудшают сложные сцены. Баланс выбирают исходя из допустимой задержки и устойчивости транспорта.

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

Практический рецепт: быстро перекодировать обычный MP4

Для базового сценария без фильтров достаточно определить кодек и rate control, а звук оставить копией. Например, при переводе H.264 в HEVC можно начать с VBR и умеренного целевого битрейта. Если аппаратный декодер поддерживает вход, --avhw уменьшит CPU-нагрузку; если появляются ошибки чтения, заменить его на --avsw.

VCEEncC64.exe --avhw -i "input.mp4" --codec hevc --vbr 8000 --audio-copy -o "output.mp4"

После первого запуска нужно посмотреть сводку: какой GPU выбран, какой профиль HEVC получился, не включилась ли неожиданная конвертация цвета, какие дорожки попали в контейнер. Затем уже добавлять preset, max bitrate и resize. Такой порядок быстрее находит ошибки, чем запуск сразу с десятками ключей.

Практический рецепт: HEVC 10 бит с сохранением HDR10

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

VCEEncC64.exe -i "hdr.mkv" --codec hevc --output-depth 10 --profile main10 --vbr 18000 --colormatrix auto --colorprim auto --transfer auto --max-cll copy --master-display copy --audio-copy --sub-copy --chapter-copy -o "hdr_hevc.mkv"

Если GPU не поддерживает 10-битный HEVC, команда завершится на инициализации. Это аппаратное ограничение. Если же обработка включает HDR-to-SDR, параметры copy для HDR-метаданных нужно убрать: выход уже не должен маркироваться как исходный HDR.

Практический рецепт: AV1 на поддерживаемом Radeon

AV1-сценарий начинается с проверки --check-hw. После подтверждения аппаратной поддержки лучше начать с простого QVBR/VBR или другого поддерживаемого режима, не включать сразу все screen-content и PA-параметры. Базовый стабильный запуск служит точкой, к которой можно вернуться при ошибке.

VCEEncC64.exe -i "input.mkv" --codec av1 --vbr 10000 --audio-copy --sub-copy -o "output_av1.mkv"

Далее имеет смысл по отдельности проверить preset, 10-битный режим, screen-content tools для соответствующих источников и pre-analysis. Если после добавления одного блока появляется сбой, причина становится очевидной. Такой метод особенно полезен для AV1, где аппаратные функции зависят от поколения VCN.

Практический рецепт: межстрочный источник

Для обычного interlaced-видео сначала определяют порядок полей. Затем можно использовать BWDIF в frame или bob-режиме. Frame сохраняет исходную кадровую частоту, bob выдаёт по кадру на поле и удваивает её. После deinterlace кодируют уже прогрессивный поток.

VCEEncC64.exe --avsw -i "capture.ts" --vpp-bwdif mode=bob,order=tff --codec hevc --vbr 8000 --audio-copy -o "progressive.mkv"

Если источник на самом деле telecine, обычный bob — не лучший выбор: лучше рассмотреть IVTC/KFM. При любом варианте нужно проверить движение и синхронизацию на коротком фрагменте, потому что ошибка field order заметна только в динамике.

Практический рецепт: уменьшение разрешения с умеренной очисткой

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

VCEEncC64.exe -i "source.mkv" --vpp-knn radius=3,strength=0.08,lerp=0.2 --output-res 1920x1080 --codec hevc --vbr 7000 --audio-copy -o "1080p.mkv"

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

Типичная ошибка: VCE unavailable

Сообщение об отсутствии VCE/VCN означает, что VCEEncC не смог инициализировать аппаратный кодировщик на выбранном устройстве. Причины: неподходящий GPU, драйвер без нужной поддержки, неверно выбранный адаптер, проблема AMF или окружения. Первое действие — --check-hw, затем список устройств и журнал инициализации.

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

Не стоит начинать с переустановки всех видеопрограмм. Если диагностическая команда не видит кодировщик, проблема находится ниже уровня конкретного контейнера и файла.

Ошибка unsupported input/output format

Сообщения о неподдерживаемом NV12, P010 или другой пиксельной модели обычно связаны с аппаратными возможностями энкодера, декодера либо конкретной комбинацией кодека и глубины. Например, запрос 10-битного HEVC требует, чтобы аппаратный путь принимал P010 и умел кодировать соответствующий профиль.

Диагностика: убрать --output-depth 10 и проверить 8-битный запуск; затем посмотреть --check-features. Если 8 бит работает, а 10 бит нет, проблема почти наверняка в поддержке глубины, а не в исходном контейнере. Аналогично проверяется AV1 и необычный профиль.

Иногда помогает переход с --avhw на --avsw, если ограничение находится в аппаратном декодере, а не в энкодере. Это разные блоки и их форматы входа/выхода не обязаны совпадать.

Ошибка аппаратного декодирования

Если --avhw завершается на конкретном файле, сначала проверяют этот же источник с --avsw. Успешное программное декодирование показывает, что кодировщик и контейнер вывода, скорее всего, исправны, а проблема находится в аппаратном decoder path или его взаимодействии с файлом.

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

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

Ошибка OpenCL и неработающие VPP-фильтры

Часть VPP зависит от OpenCL. Если VCEEncC кодирует без фильтров, но падает при их включении, нужно проверить --check-clinfo. На Linux дополнительно важны ICD и системная библиотека OpenCL; на Windows — корректная установка драйвера и видимость нужного GPU.

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

При обработке 4K/8K несколько временных фильтров могут потреблять значительный объём видеопамяти. Ошибка allocation в таком случае лечится уменьшением сложности цепочки, а не сменой битрейта энкодера.

Ошибки звука и контейнера

Если видео кодируется, но muxer не создаёт выход, следует смотреть строку, где перечислены выбранные потоки. Неподдерживаемый аудиокодек в MP4, некорректный codec tag, повреждённая дорожка или невозможная комбинация subtitle/container относятся к мультиплексированию, а не к VCE/VCN.

Для диагностики можно временно оставить только видео. Если файл создаётся, затем добавить --audio-copy, потом субтитры и другие элементы. Такой порядок быстро показывает, какой поток ломает контейнер.

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

Проблемы с рассинхронизацией

Постепенно растущий рассинхрон часто возникает из-за неверной частоты кадров или обработки VFR/RFF. В этом случае --audio-delay не поможет: он добавляет постоянный сдвиг, а ошибка продолжит накапливаться. Нужно проверить входной fps, режим avsync, timebase и timestamps.

Для VFR, который нужно сохранить, используют соответствующий режим и passthrough временных меток. Для конечного устройства, которому нужен CFR, forcecfr может корректировать количество кадров на основании PTS. Но такой перевод неизбежно меняет кадровую структуру, поэтому результат нужно оценить на движении.

Если рассинхрон появляется только после decimate/IVTC, проблема может быть в выбранной временной модели после удаления кадров. Сначала следует проверить видеопоток без звука и timecode, затем вернуть аудио.

Проблемы с разрешением и выравниванием

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

Некоторые поколения имеют аппаратные особенности для отдельных кодеков. Если стандартное 1920×1080 неожиданно кодируется с внутренним выравниванием иначе, важно отличать реальную геометрию видимого кадра от coded size и padding. Такие особенности нельзя исправить произвольным crop без понимания причины.

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

Как читать итоговую статистику

Строка encoded N frames показывает число обработанных кадров, скорость, средний битрейт и размер. Далее выводится время работы и показатели загрузки. Они позволяют понять, соответствует ли фактический результат ожиданиям: например, VBR 8 Мбит/с не обязан дать ровно 8000 кбит/с на коротком или простом ролике.

Статистика по типам кадров и QP помогает увидеть структуру потока. Если B-кадры были запрошены, но в отчёте их нет, нужно проверить поддержку и фактические настройки. Аналогично pre-analysis и LTR отображаются в сводке перед стартом.

Если скорость внезапно снизилась после добавления фильтра, сравнение двух логов обычно сразу показывает, какой VPP появился и изменилась ли загрузка GPU/VE. Это гораздо информативнее субъективного ощущения новая команда медленнее.

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

Прямые аналоги различаются прежде всего аппаратной платформой и уровнем интеграции. NVEncC и QSVEncC имеют близкую идеологию командной строки и ориентируются соответственно на NVIDIA и Intel. FFmpeg универсальнее по источникам и кодекам, но его AMF-интерфейс и набор встроенных фильтров организованы иначе. HandBrake удобнее пользователям, которым важнее готовые профили и графический интерфейс, чем низкоуровневое управление VCE/VCN.

Программа	Лучше подходит для	Главное ограничение
VCEEncC	Тонкая настройка аппаратного кодирования AMD и GPU-VPP	Требуется совместимый AMD VCE/VCN
NVEncC	Детальное аппаратное кодирование на NVIDIA	Привязан к NVIDIA NVENC
QSVEncC	Аппаратное кодирование на Intel Quick Sync	Нужна совместимая Intel Graphics
FFmpeg	Универсальные конвейеры, форматы, протоколы и фильтры	Синтаксис сложен, AMF-настройки отличаются
HandBrake	Профильное перекодирование файлов с удобным GUI	Меньше низкоуровневого контроля над VCE/VCN

Если компьютер построен вокруг Radeon и требуется управлять именно аппаратным энкодером AMD, VCEEncC обычно логичнее универсального фронтенда: доступны диагностика устройства, специализированные параметры AMF и большая VPP-цепочка. Если важнее единый скрипт для десятков протоколов и кодеков, FFmpeg гибче. При смене GPU-платформы на NVIDIA или Intel ближайшие по подходу инструменты — NVEncC и QSVEncC.

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

Как выбрать настройки без лишних экспериментов

Рациональная последовательность настройки начинается с минимальной рабочей команды. Сначала проверяется GPU, затем кодек, базовый rate control и контейнер. После этого добавляются глубина, профиль и ограничения битрейта. Только когда кодирование стабильно, стоит включать фильтры, HDR/Dolby Vision, дополнительные дорожки и предварительный анализ.

1. Проверить --check-hw и --check-features для нужного device.
2. Запустить короткий файл без VPP и без сложных параметров.
3. Выбрать режим качества или битрейта, зафиксировать preset.
4. Добавить 10 бит, профиль, уровень и HDR-метаданные, если они действительно нужны.
5. Подключать VPP по одному логическому блоку: геометрия, деинтерлейс, очистка, цвет, резкость.
6. Вернуть звук, субтитры, главы и вложения, проверить структуру контейнера.
7. Сохранить рабочую команду или option file и использовать её в batch-сценарии.

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

Когда VCEEncC особенно удобен

Программа хорошо подходит для автоматизированной домашней медиатеки на Radeon, перекодирования записей ТВ, подготовки нескольких разрешений, аппаратного AV1 на совместимых GPU и интеграции с AviSynth/VapourSynth. Она также полезна как исследовательский инструмент: диагностические команды и детальный лог позволяют увидеть реальные возможности кодировщика, а не опираться только на маркетинговое название видеокарты.

Сильная сторона VCEEncC — сочетание аппаратного энкодера с богатым VPP и контейнерной обработкой. Во многих задачах можно прочитать исходник, отфильтровать, перекодировать видео, скопировать звук и субтитры, перенести главы и записать MKV одной командой. Это уменьшает количество временных файлов и точек, где могут потеряться метаданные.

Ограничение той же архитектуры — зависимость от AMD VCE/VCN. Там, где аппаратный блок не поддерживает нужный кодек, профиль или глубину, VCEEncC не может заменить отсутствующее железо. Для программного максимального качества или другой GPU-платформы логичнее выбрать специализированный энкодер, соответствующий задаче.

Фильтры цвета: curves, tweak и коррекция баланса

Помимо полноценного преобразования color space, VCEEncC содержит фильтры локальной коррекции изображения. Curves позволяет задавать кривые для яркости и RGB-каналов либо выбирать готовые характерные формы вроде повышения контраста. Такие инструменты подходят для осмысленной цветокоррекции, но не заменяют корректную матрицу и transfer: сначала следует убедиться, что сигнал интерпретируется правильно, и только потом менять художественный вид.

Фильтры типа tweak дают прямое управление яркостью, контрастом, насыщенностью, гаммой и оттенком. Их удобно использовать для небольшого исправления источника, когда полноценный grading не нужен. При этом большой подъём контраста или насыщенности способен вывести значения к границам диапазона и ухудшить последующее сжатие. Поэтому после коррекции стоит проверить clipping и уровни, особенно при TV range.

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

Если несколько цветовых фильтров включены одновременно, их порядок становится частью результата. Например, изменение гаммы до tone mapping и после него — не одно и то же. В сложной команде лучше логически разделять техническое преобразование HDR/SDR и творческую коррекцию, чтобы не потерять контроль над тем, на каком этапе меняется сигнал.

Удаление ореолов, ringing и компрессионных дефектов

Для старых источников и материала после нескольких поколений кодирования характерны ringing, mosquito noise и светлые или тёмные ореолы вокруг контрастных границ. VCEEncC предлагает dehalo, fine-dehalo и HQDering, которые работают по разным маскам и критериям. Их задача — уменьшить конкретные дефекты, а не повысить общую чёткость.

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

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

Такие фильтры стоит ставить до финального sharpen. Если сначала усилить контур, алгоритму удаления ореола придётся работать с уже изменённой границей. После коррекции полезно проверить и статичные крупные объекты, и мелкий движущийся текст — побочные эффекты могут проявляться по-разному.

Работа с дополнительными источниками звука и субтитров

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

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

Дополнительные subtitle source полезны для внешних SRT/ASS. Их можно оставить отдельной дорожкой или использовать для прожига. При автоматизации удобно назначать language и title сразу при mux, чтобы готовый файл не требовал дополнительного редактирования метаданных.

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

Захват и avdevice

Через мультимедийную подсистему VCEEncC может видеть входные устройства, доступные как avdevice. Специальная диагностическая команда выводит перечень таких источников. Это не превращает программу в полноценную студию захвата, но позволяет использовать её в автоматизированных цепочках, где кадры поступают не из заранее готового файла.

Для входного устройства могут потребоваться явные параметры pixel format, разрешения и частоты кадров. В отличие от обычного файла, захват не всегда предоставляет удобный набор метаданных заранее, поэтому несогласованный формат приводит к ошибке ещё до запуска энкодера. Сначала полезно проверить источник простым выводом без тяжёлого VPP.

Live-вход особенно чувствителен к latency и переполнению буферов. Тяжёлый temporal denoise, RIFE или глубокий lookahead могут сделать обработку медленнее реального времени. В файловой задаче это только увеличивает время, а при захвате означает потерю возможности обрабатывать поток с заданной скоростью.

Если нужна сложная маршрутизация нескольких устройств, микширование и live-композиция, специализированный захватчик или FFmpeg обычно удобнее. VCEEncC в таком сценарии разумно оставлять аппаратным кодировщиком или VPP-узлом.

Option file и воспроизводимые профили

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

В option file имеет смысл хранить только то, что действительно постоянно: codec, preset, rate control, VPP и правила работы с дорожками. Device id, абсолютные пути к моделям, логотипам или временным каталогам лучше отделять, если конфигурация должна быть переносимой. Иначе профиль формально одинаковый, но работает только на одной машине.

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

Профиль также помогает избегать скрытого дрейфа настроек. Если каждый запуск собирается вручную, легко забыть одну опцию HDR или изменить max bitrate. С фиксированным option file рабочий процесс становится повторяемым, что особенно важно для большого архива.

Кодировка текста, пути и специальные символы

VCEEncC ориентируется на UTF-8, что удобно для путей и метаданных на разных языках. Однако старые AviSynth-сценарии и вспомогательные инструменты могут ожидать системную кодовую страницу. Для таких случаев предусмотрена настройка process codepage. Это не параметр качества видео, а способ согласовать строковый ввод между компонентами.

Пути с пробелами нужно заключать в кавычки. В Windows дополнительную сложность создают символы, которые обрабатывает cmd.exe или PowerShell ещё до запуска VCEEncC. Если строка работает в одном shell и ломается в другом, причина может быть в экранировании, а не в программе. Для длинных путей к шейдерам, моделям и субтитрам option file снижает риск ошибок.

Метаданные с двоеточиями, запятыми и кавычками тоже требуют внимания, потому что часть параметров VCEEncC использует эти знаки как разделители. В сложных значениях разумно сначала проверить одну строку metadata, а затем добавлять остальные. Ошибка синтаксиса в середине длинного списка часто выглядит как проблема совсем другого ключа.

В кроссплатформенных скриптах стоит избегать жёсткого копирования Windows-путей в Linux и наоборот. Сами параметры VCEEncC похожи, но пути, shell quoting и доступность внешних библиотек различаются.

Управление потоками CPU и affinity

Хотя основной видеокодировщик работает на GPU, CPU остаётся задействован в demux, программном декодировании, VMAF, аудио, обработке контейнера и части служебных задач. VCEEncC умеет задавать thread affinity для всего процесса и отдельных групп потоков. Это полезно на системах с гибридными ядрами или несколькими NUMA/CCX-доменами.

Можно привязать процесс к logical или physical cores, использовать группы performance/efficiency cores либо маску affinity. Такая настройка имеет смысл только при измеримой проблеме: например, когда фоновая задача конкурирует с программным декодером. Без причины жёсткая привязка способна, наоборот, ограничить производительность.

На современных Ryzen выбор конкретного L3/CCX иногда используют для воспроизводимых бенчмарков или снижения миграции потоков. Но аппаратный VCE/VCN от этого напрямую быстрее не становится. Улучшение возможно только если CPU-часть была узким местом.

Для повседневного транскодирования автоматическое планирование ОС обычно достаточно. Affinity — инструмент тонкой диагностики и распределения ресурсов, а не обязательный пункт каждого пресета.

Логи в файл и разбор ошибок в batch-очереди

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

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

В автоматическом скрипте следует проверять exit code процесса, а не только существование выходного файла. Неудачное кодирование может оставить неполный контейнер. Следующий этап не должен считать такой файл готовым только потому, что он появился на диске.

Если задача допускает повтор, полезно классифицировать сбои: аппаратный decode можно повторить с avsw, ошибку выбранного GPU — с другим device, но неподдерживаемый codec/profile не стоит бесконечно перезапускать. Такой подход делает очередь устойчивой без скрытого ухудшения параметров.

Как оценивать результат после фильтрации

Проверка VCEEncC не заканчивается сообщением об успешном кодировании. После сильного VPP нужно оценить несколько типов сцен: плавные градиенты для deband, мелкую текстуру для denoise, контрастные линии для sharpen/dehalo, движение для temporal-фильтров и яркие HDR-участки для tone mapping. Один случайный кадр не раскрывает все дефекты.

Особенно полезно сравнивать одинаковые фрагменты до и после на стоп-кадрах и в движении. Temporal ghosting почти незаметен на одиночном кадре, а ringing, наоборот, легко увидеть на увеличенном изображении. Для HDR требуется корректный дисплейный тракт или анализ значений, иначе субъективная проверка может быть ошибочной.

SSIM, PSNR и VMAF дополняют визуальную оценку, но не должны определять настройку в одиночку. Denoise может повысить метрику за счёт удаления различий, которые на самом деле являются естественным зерном. Тест должен соответствовать назначению: архив, стриминг, мобильное устройство и мастер-файл предъявляют разные требования.

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