QSVEncC позволяет перекодировать видео с помощью Intel Quick Sync Video, выбирать H.264, HEVC, VP9, AV1 и MPEG-2, управлять качеством и битрейтом, применять фильтры перед кодированием, переносить аудио, субтитры и главы, а также собирать готовый файл в нужном контейнере.

Главная особенность QSVEncC — прямой доступ к возможностям аппаратного медиаблока Intel через командную строку. Вместо фиксированного набора профилей здесь задаются вход, декодер, кодек, режим контроля качества, GOP, цветовые параметры, фильтры, правила работы со звуковыми и текстовыми дорожками, контейнер и служебные метаданные. Такая схема полезна, когда нужно не просто переконвертировать файл, а воспроизводимо управлять всей цепочкой обработки и понимать, какие параметры действительно принял драйвер.

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

Как устроена работа QSVEncC

QSVEncC принимает параметры в командной строке и выводит подробный журнал запуска: сведения о процессоре и графике, выбранном устройстве, версии аппаратного API, типе декодирования, формате входных кадров, активных VPP-фильтрах, кодеке и профиле вывода, режиме управления качеством, GOP, количестве опорных кадров и дополнительных функциях. Во время кодирования добавляются прогресс, скорость в кадрах в секунду, текущий битрейт, оценка оставшегося времени и показатели загрузки. Благодаря этому журнал служит одновременно подтверждением настроек и первым источником данных при поиске ошибки.

Минимальная команда состоит из входа и выхода. Если кодек не указан, используется H.264; при обычном файле тип считывателя определяется автоматически. Контейнер вывода обычно выбирается по расширению имени. Это делает короткие команды действительно короткими, но для повторяемых сценариев лучше явно задавать критические параметры: кодек, режим качества, глубину цвета, способ декодирования и действия с аудио. Тогда изменение расширения или состава исходника не меняет смысл задания незаметно для пользователя.

QSVEncC.exe -i input.mkv -o output.mp4

Для типичного аппаратного транскодирования добавляют --avhw, а затем указывают кодек и режим качества. Например, HEVC с интеллектуальным постоянным качеством можно задать так:

QSVEncC.exe --avhw -i input.mkv -c hevc --icq 23 --audio-copy -o output.mkv

Проверка аппаратных возможностей

Перед настройкой сложной команды полезно убедиться, что QSV вообще доступен. --check-hw проверяет возможность аппаратного кодирования выбранным устройством, а --check-device показывает обнаруженные устройства. В системе с интегрированной графикой и дискретной Intel Arc это особенно важно: номер устройства определяет, где именно выполняется кодирование. Явный выбор выполняется через --device; значение auto оставляет подбор программе.

--check-features — одна из ключевых диагностических команд. Она показывает не абстрактный список возможностей QSV, а фактическую поддержку для текущей комбинации GPU, драйвера, кодека и режимов: доступные варианты rate control, 10-битный вывод, B-кадры и другие функции. Если хочется сохранить результат для просмотра в браузере, предусмотрен --check-features-html. Такая проверка надежнее предположения, что определенная функция должна быть у конкретного поколения Intel.

Дополнительные проверки помогают локализовать неполадки. --check-environment выводит окружение, --check-lib и --check-impl показывают версии Media SDK/VPL, --check-clinfo проверяет OpenCL, --check-encoders и --check-decoders перечисляют доступные аудиокодеки, --check-profiles — профили заданного кодека, --check-formats — форматы контейнеров. Если фильтр или аудиокодек не находится, эти команды позволяют проверить реальную сборку без догадок.

QSVEncC.exe --check-hw
QSVEncC.exe --check-device
QSVEncC.exe --check-features
QSVEncC.exe --check-environment
QSVEncC.exe --check-clinfo

Входные файлы и выбор декодирования

QSVEncC умеет получать кадры несколькими способами. Для обычных медиафайлов используются считыватели на базе библиотек FFmpeg: --avhw включает аппаратное декодирование там, где оно поддерживается, а --avsw — программное. Если аппаратный декодер не подходит конкретному формату или ведет себя нестабильно, программное чтение становится практичной альтернативой. И наоборот, при длинной массовой перекодировке поддерживаемого материала аппаратный decode снижает нагрузку на CPU и позволяет построить цепочку decode–VPP–encode вокруг видеоблока Intel.

По расширению автоматически выбираются и специализированные считыватели: AVS передается Avisynth, VPY — VapourSynth, AVI может читаться собственным AVI reader, Y4M — YUV4MPEG2 reader, YUV — raw reader. Для raw-входа недостаточно имени файла: нужно задать разрешение, частоту кадров и цветовой формат. Через --input-csp доступны YUV 4:2:0, 4:2:2 и 4:4:4 с различной разрядностью, включая 9/10/12/14/16 бит там, где этот формат поддерживает выбранный reader.

Если файл содержит несколько видеопотоков, --video-track выбирает поток по относительному размеру разрешения, а --video-streamid — по идентификатору stream. Это полезно для сложных контейнеров, где кроме основного видео присутствуют дополнительные представления. Для файлов с необычной структурой можно принудительно задать входной формат через --input-format.

Когда анализ контейнера не успевает обнаружить дорожки, имеет смысл увеличить объем или время предварительного анализа, а не сразу обвинять muxer. QSVEncC предоставляет параметры анализа входа и --input-probesize. Это особенно актуально для транспортных потоков, записей вещания и файлов, где заголовки дорожек встречаются не у самого начала.

Потоковый ввод через stdin

Знак - вместо имени файла означает pipe. Y4M удобно передавать из внешней программы, потому что заголовок Y4M содержит геометрию и частоту кадров. Для одновременной передачи необжатого видео и аудио можно использовать контейнер NUT. Такой подход позволяет оставить сложную подготовку кадров в FFmpeg, Avisynth или VapourSynth, а аппаратное кодирование поручить QSVEncC.

ffmpeg -i input.mkv -an -pix_fmt yuv420p -f yuv4mpegpipe - | QSVEncC.exe --y4m -i - -c hevc --icq 23 -o output.hevc

У pipe есть принципиальное ограничение: поток обычно нельзя произвольно перематывать. Поэтому функции, требующие повторного доступа к разным частям исходника, могут быть отключены. В частности, файл-сплит параллельного кодирования рассчитан на seekable input и с обычным одиночным pipe не используется.

Кодеки вывода и глубина цвета

Основные аппаратные варианты выбираются через -c или --codec: H.264/AVC, HEVC, MPEG-2, VP9 и AV1. Набор, который реально запустится, определяется графическим устройством. Сам факт наличия имени AV1 в справке не означает, что старое iGPU сможет его кодировать. Аналогично 10-битный режим, конкретный профиль, B-кадры и отдельные дополнительные инструменты зависят от поколения медиаблока и драйвера.

--output-depth 8 и --output-depth 10 управляют глубиной выходного видео. Десять бит особенно часто используют с HEVC и AV1, в том числе для HDR, но глубина не должна задаваться для качества вообще: она должна соответствовать задаче, декодерам целевых устройств и возможностям выбранного профиля. --output-csp задает yuv420, yuv422, yuv444 или rgb, однако аппаратный encoder поддерживает не все сочетания кодека, цветовой субдискретизации и глубины; окончательный ответ снова дает --check-features и журнал старта.

Кроме QSV-кодеков существует режим -c raw, при котором кадры проходят через выбранную цепочку чтения и фильтрации, но не кодируются. Это удобно, если QSVEncC используется как VPP-процессор перед другим encoder. Есть также форма av_xxx для доступных avcodec-энкодеров; их список проверяется через --check-encoders, а параметры такого encoder передаются через --avcodec-prms. Такой путь не следует путать с аппаратным QSV-кодированием: backend и набор допустимых настроек будут другими.

Режимы качества и битрейта

По умолчанию QSVEncC использует ICQ — Intelligent Constant Quality. Пользователь задает целевой уровень качества, а битрейт изменяется в зависимости от сложности материала. Для ICQ и LA-ICQ меньшее числовое значение означает более высокое качество. Это удобный выбор для файлового хранения, когда важнее визуальная стабильность между простыми и сложными сценами, чем заранее известный размер файла.

LA-ICQ добавляет lookahead, если конкретный аппаратный encoder поддерживает этот режим. Анализ будущих кадров способен улучшить распределение решений, но увеличивает требования к буферам и не гарантируется на каждом GPU. Поэтому нельзя считать --la-icq универсально лучше ICQ: если режим отсутствует в feature table, QSVEncC либо применит fallback, либо сообщит об ограничении. Длину анализа для поддерживаемых сценариев настраивает --la-depth.

CQP задает квантизатор напрямую. Можно указать одно значение или отдельные QP для I, P и B-кадров. Документация рекомендует общий порядок I < P < B, то есть опорным кадрам отдавать больше качества. CQP работает предсказуемо как режим фиксированного квантования, но итоговый размер файла заранее не контролируется. Он удобен для тестовых прогонов, промежуточных файлов и сценариев, где постоянный уровень квантования важнее целевого битрейта.

CBR и VBR работают с целевым битрейтом в кбит/с. CBR нужен там, где поток должен держаться около заданной скорости передачи, VBR допускает перераспределение битов между сценами. AVBR — еще один аппаратный вариант адаптивного VBR. Для задач, где нужен жесткий верхний предел, вместе с поддерживаемым bitrate mode применяют --max-bitrate и при необходимости --vbv-bufsize. Это важнее для вещательных ограничений, совместимости с профилем и управляемого канала, чем для домашнего архива.

QVBR совмещает целевой битрейт с целевым качеством. Режим особенно полезен, когда нельзя полностью отпустить размер, как в ICQ, но хотелось бы не тратить биты на простые сцены только ради постоянного потока. LA и LA-HRD — lookahead-варианты bitrate control; VCM ориентирован на сценарии видеоконференций. Наличие каждого варианта определяется устройством, поэтому список в справке — это перечень интерфейса QSVEncC, а не обещание, что все режимы одновременно доступны на любом Intel GPU.

Режим	Что задает пользователь	Когда удобен
ICQ	Уровень качества	Файловое кодирование с переменным битрейтом
LA-ICQ	Качество + lookahead	Когда аппаратно доступен анализ будущих кадров
CQP	QP для кадров	Прямой контроль квантования без цели по размеру
CBR	Битрейт	Ограниченный канал и потоковые задачи
VBR	Средний/целевой битрейт	Контроль размера с гибкостью между сценами
QVBR	Битрейт и качество	Компромисс между ограничением потока и визуальным качеством

Target Usage: от best до fastest

-u или --quality выбирает одну из семи ступеней target usage: best, higher, high, balanced, fast, faster, fastest. Это не готовые пресеты кодека в духе программного x264/x265, а запрос к аппаратному encoder на баланс качества и скорости. Драйвер может поддерживать не все семь точек и заменить запрошенную ближайшей допустимой; подобная коррекция появляется в журнале строкой о том, что значение изменено драйвером. Если команда просит best, а лог показывает другое фактическое значение, ориентироваться нужно на лог.

Для оценки режима лучше менять один фактор за раз: сначала зафиксировать codec, ICQ/QVBR/CQP и фильтры, затем сравнивать target usage. Иначе изменение одновременно target usage, ICQ, GOP и числа B-кадров не позволяет понять, какой параметр повлиял на результат.

Lookahead, ExtBRC и дополнительные инструменты rate control

--la-depth задает глубину lookahead в кадрах для режимов, где это поддерживается. Большая глубина не является бесплатным улучшением: растут буферы, задержка и требования к памяти, а максимум может зависеть от interlace и реализации драйвера. --la-quality управляет качеством lookahead-прохода — от более быстрого анализа до более полного. Для AV1 QSVEncC также позволяет сочетать глубину lookahead с базовыми режимами и ExtBRC там, где платформа это поддерживает.

--extbrc включает расширенный bitrate control Intel. --i-adapt, --b-adapt, adaptive reference и другие связанные функции имеют смысл только тогда, когда feature query подтверждает их поддержку. QSVEncC специально печатает предупреждения, если параметр недоступен или был изменен. Это важная часть архитектуры программы: командная строка описывает желаемую конфигурацию, но финальное решение принимает аппаратный драйвер.

Для некоторых старших поколений iGPU существует отдельная защита от проблем HEVC 10-bit FF в сочетании с EncTools. По умолчанию QSVEncC может отключить затрагиваемые настройки и вывести предупреждение, чтобы избежать поврежденного изображения. Поэтому совет форсировать каждую опцию, даже если программа ее сняла опасен: автоматический workaround появился именно потому, что допустимость набора параметров зависит не только от синтаксиса, но и от конкретной реализации драйвера.

GOP, B-кадры и опорные кадры

--gop-len задает максимальную длину GOP, --bframes — количество B-кадров в поддерживаемых кодеках, --ref — число опорных кадров. Также доступны B-pyramid, открытый/закрытый GOP и параметры адаптивной вставки кадров. Эти значения влияют не только на степень сжатия, но и на задержку, требования к decoder и совместимость конкретного профиля.

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

Не все кодеки интерпретируют параметры одинаково. Например, доступность B-кадров в AV1 и HEVC зависит от реализации, а драйвер способен уменьшить число references или изменить target usage. Поэтому после запуска стоит читать блок Output, Ref frames, Bframes, Max GOP Length и строки о корректировках. Эта информация показывает фактическую структуру, а не только исходную команду.

PG, FF и Hyper Mode

--function-mode позволяет выбирать способ использования QSV. В режиме PG часть работы может задействовать исполнительные блоки GPU, а FF ориентирован на fixed-function медиаблок; эквивалентная короткая опция для FF — --fixed-func. Режимы отличаются не только загрузкой графических EU: набор функций также может быть разным. Поэтому переход на FF ради низкой загрузки GPU иногда меняет доступность B-кадров, lookahead или других инструментов.

Если поставить --function-mode auto, QSVEncC пытается выбрать подходящий режим. Это хороший исходный вариант, когда нет конкретной причины форсировать FF или PG. Принудительное указание оправдано при диагностике, воспроизводимом сравнении или когда известна особенность нужного GPU. В журнале видно, был ли запрос принят: сообщения вида PG is not supported, switched to FF означают не сбой, а согласование параметров с драйвером.

Hyper Mode относится к Intel Deep Link Hyper Encode и предназначен для совместной работы подходящих Intel GPU. Режимы off, on и adaptive выбираются через --hyper-mode. Настройки должны поддерживаться обоими устройствами, иначе QSVEncC вынужден отключать несовместимые функции. Для такой схемы особенно важно читать лог выбора GPU и не переносить настройки с одиночного encoder без проверки.

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

--parallel — отдельный механизм ускорения, не равный Hyper Mode. Он делит seekable-файл на части и запускает несколько encoder-потоков параллельно. Можно указать число потоков или auto. Подход способен задействовать несколько GPU либо несколько media-function блоков, но эффективность зависит от симметрии устройств, декодирования, пропускной способности памяти и PCIe, а также от сложности фильтров.

У параллельного режима есть четкие ограничения. Он автоматически отключается для обычного pipe-входа, несиквируемого источника, нестабильных временных меток, raw-вывода, dynamic RC, trim, timecode/tcfile, keyfile/key-on-chapter, оценки SSIM/PSNR/VMAF, прожига субтитров и ряда кадровых интерполяций. Это не произвольные запреты: разные части файла должны обрабатываться независимо, а перечисленные функции требуют глобального контекста, точной общей временной шкалы или сравнения с итоговым потоком.

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

--parallel-force-large-memory-filters снимает автоматическое ограничение числа параллельных ветвей для фильтров, требующих много видеопамяти. Использовать его стоит только при понимании расхода VRAM: слишком агрессивная параллельность способна привести к ошибке выделения памяти или даже снизить производительность из-за конкуренции за ресурсы.

QSVEncC.exe --avhw -i input.mkv -c hevc --icq 23 --parallel auto --audio-copy -o output.mkv

Буферы и асинхронность

--async-depth задает глубину асинхронного QSV pipeline. Автоматический режим обычно выбирает разумное значение, а увеличение глубины иногда помогает лучше загрузить аппаратный блок. Однако больше — не всегда быстрее: растет потребление памяти, а чрезмерная глубина может ухудшать эффективность кэшей и увеличивать задержку. Менять параметр стоит после того, как определено реальное узкое место.

--input-buf регулирует входной буфер в кадрах, --output-buf — накопление выходных данных перед записью на диск. Больший output buffer может уменьшить фрагментацию и количество мелких операций записи, но слишком большой буфер приводит к редким крупным сбросам и способен ухудшить поведение хранилища. Для большинства задач значения по умолчанию логичнее ручного максимума.

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

Если используется avhw/avsw reader, QSVEncC может переносить аудиодорожки вместе с видео. --audio-copy без аргументов копирует все дорожки; можно указать номера, языковые коды или исключения через префикс !. Это удобно для MKV с несколькими языками: вместо ручного перечисления всего состава можно оставить нужные языки либо исключить комментарии по номеру дорожки.

--audio-copy
--audio-copy 1,2
--audio-copy eng,jpn
--audio-copy !1

Когда исходный аудиокодек не подходит контейнеру или целевому устройству, применяется --audio-codec. Доступные encoder проверяются через --check-encoders. Параметр тоже умеет адресовать дорожку по номеру или языку, поэтому одну дорожку можно перекодировать, а другую оставить без изменений. --audio-encode-other-codec-only полезен в пакетной обработке: если вход уже имеет целевой аудиокодек, он копируется; перекодирование выполняется только для других форматов.

Помимо кодека доступны битрейт, частота дискретизации, число каналов, channel layout, фильтры и resampler. Конкретные имена параметров зависят от сборки и выбранного audio encoder, поэтому длинный универсальный шаблон для всех файлов хуже простого правила: сначала посмотреть дорожки, затем определить, какие можно копировать, и перекодировать только несовместимые. Лишнее аудиокодирование ухудшает качество и тратит время.

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

Субтитры, главы, data и attachments

--sub-copy копирует субтитры из контейнера, причем дорожки также можно выбирать по номеру и языку. --sub-codec предназначен для преобразования формата субтитров, если это поддерживает сборка. Отдельный файл подключается через --sub-source. Такая схема позволяет собрать новый MKV с видео, несколькими аудио и нужными субтитрами без обязательного обращения к внешнему muxer.

Копирование субтитров и их прожиг — разные операции. --sub-copy оставляет отдельную дорожку, которую плеер может включать или выключать. --vpp-subburn рисует текст или графические субтитры прямо на кадрах до кодирования. После прожига удалить их нельзя; кроме того, этот фильтр влияет на возможность параллельной обработки частей файла.

Главы переносятся через --chapter-copy. При необходимости вместо них можно загрузить внешний chapter-файл в Nero, Apple или Matroska-формате через --chapter; одновременно использовать внешний файл и copy нельзя. --chapter-no-trim определяет поведение глав относительно обрезки. Для MKV также полезны --data-copy и --attachment-copy, когда нужно сохранить служебные дорожки и вложения, например шрифты.

Метаданные видео, аудио и субтитров можно копировать или задавать выборочно. Это лучше, чем безусловное копирование всего metadata-блока: при изменении разрешения, HDR, языка или назначения дорожек старые теги иногда становятся неверными. Для архива разумно сохранять названия и языки, но технические поля проверять по смыслу.

Контейнеры и muxer

Формат вывода обычно выводится из расширения файла. Для output.mp4 выбирается MP4, для output.mkv — Matroska. Через --output-format формат можно задать явно. Для elementary stream H.264/HEVC используется raw-вывод. Список muxer, присутствующих в конкретной сборке, показывает --check-formats.

Контейнер ограничивает допустимый набор дорожек. Если выбранный аудио- или субтитровый codec плохо сочетается с MP4, проблема не решается параметрами QSV encoder: нужно изменить codec, контейнер или схему mux. Matroska обычно гибче для многодорожечных архивов, тогда как MP4 часто удобнее для бытовой совместимости. QSVEncC не отменяет правила самих контейнеров.

--video-tag позволяет задать tag видеодорожки, например hvc1 для HEVC в MP4, если этого требует дальнейший workflow. Для video metadata есть copy/clear и назначение отдельных полей. Это полезно при подготовке файлов для программ, которые различают варианты FourCC/tag даже при одинаковом видеокодеке.

Обрезка по кадрам и быстрый seek

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

--trim 0:1000,2000:3000
--trim 2000:0

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

Trim несовместим с некоторыми механизмами, которым нужна непрерывная исходная временная шкала; например, parallel автоматически отключается. Кроме того, --avsync forcecfr и vfr имеют свои ограничения при использовании trim. Перед сложной нарезкой разумно сначала определить, что важнее: точные кадровые диапазоны или полное сохранение исходных timestamp.

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

--avsync управляет тем, как QSVEncC относится к входным PTS. В режиме auto программа выбирает стандартное поведение. forcecfr дублирует или удаляет кадры, когда это нужно для постоянной частоты и синхронизации со звуком. vfr сохраняет временные метки источника и разрешает переменную частоту кадров; он рассчитан на avsw/avhw reader.

--timestamp-passthrough передает исходные timestamp и подразумевает VFR. Есть вывод и чтение timecode, а также явный --timebase. Это уже инструменты для тех случаев, где обычной CFR/VFR логики недостаточно: монтажные цепочки, источники с нетривиальными PTS, промежуточный raw/NUT и анализ рассинхронизации.

При жалобе на уезжающий звук нельзя автоматически ставить forcecfr всем файлам. Сначала нужно определить, является ли источник VFR, содержит ли RFF, корректно ли определена частота кадров и нет ли пропусков в транспортном потоке. ForceCFR может действительно выровнять проблемную запись, но ценой добавления или удаления кадров. Для нормального VFR правильнее сохранить временную структуру, чем превращать ее в CFR без необходимости.

VPP-фильтры и фиксированный порядок обработки

QSVEncC содержит большую цепочку Video Pre-Processing. Существенная деталь: фильтры применяются в заранее определенном порядке независимо от того, в какой последовательности они записаны в командной строке. Поэтому перестановка аргументов не меняет pipeline так, как это бывает в некоторых фильтр-графах. Если результат комбинации кажется неожиданным, нужно смотреть документированный порядок и блок VPP в журнале.

В начале цепочки находятся преобразования цвета и tone mapping, затем обработка RFF/логотипа и deinterlace/IVTC, далее шумоподавление и восстановление деталей, масштабирование, резкость, коррекции, геометрические фильтры, deband, прожиг субтитров и другие операции. Фактический список обширен и меняется по мере сборки, но принцип остается: VPP — это последовательная обработка кадров до encoder.

Часть фильтров основана на media-function блоках Intel, часть выполняется через OpenCL, libplacebo или другие библиотеки. Отсюда возникают разные требования к памяти и драйверу. Опция может присутствовать в справке, но для конкретного алгоритма понадобятся OpenCL, Vulkan/libplacebo, OpenVINO или дополнительная модель. При отсутствии зависимости лучше выбирать альтернативный фильтр, а не ожидать, что одинаковое имя автоматически означает одинаковый backend.

Деинтерлейс и обратное телесинирование

Для чересстрочного материала доступны как media-function deinterlace, так и программно-вычислительные варианты: AFS, bwdif, yadif, NNEDI, RTGMC-подобная цепочка, KFM, decomb и другие. У них разные задачи и стоимость. Простой hardware deinterlace подходит для скорости, тогда как более тяжелые алгоритмы полезны, когда нужно лучше сохранить тонкие линии и движение.

Перед выбором фильтра важно правильно указать field order или позволить программе его определить, если источник надежно размечен. Ошибочный TFF/BFF дает характерное дерганье движения независимо от качества encoder. Для источников с RFF и смешанными структурами следует отдельно учитывать IVTC/decimate и особенности конкретного фильтра; простое преобразование 29,97i в 59,94p не всегда соответствует исходной структуре контента.

IVTC и decimation меняют не только картинку, но и временную шкалу, поэтому после них особенно важен контроль длительности, frame rate и audio sync. Если результат стал длиннее/короче или звук уходит, нужно проверять VPP-log и avsync, а не компенсировать проблему произвольным изменением битрейта или GOP.

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

QSVEncC включает разные семейства denoise: KNN, PMD, NLMeans, HQDN3D, smooth, DCT, FFT3D, BM3D, convolution3d, degrain и media-function denoise. Алгоритмы различаются по вычислительной цене и характеру артефактов. Сильное подавление шума может заметно снизить требуемый битрейт, но также стирает пленочное зерно, мелкую текстуру и тонкие линии. Поэтому denoise должен решать конкретную проблему источника, а не быть обязательной стадией каждого encode.

После шумоподавления доступны unsharp, edgelevel, CAS, msharpen, detailsharpen, warpsharp, detail-enhance и другие средства работы с деталями. Усиление резкости после агрессивного denoise часто создает искусственные контуры; лучше сначала подобрать минимально достаточную очистку, а затем добавлять умеренное усиление. Проверять результат следует на реальных сложных сценах, а не только на статичном стоп-кадре.

Изменение разрешения

Разрешение задается через --output-res. Нулевое измерение может означать сохранение соответствующего исходного размера, отрицательное служебное значение позволяет вычислить вторую сторону с сохранением пропорций. Есть режимы preserve_aspect_ratio для увеличения или уменьшения в заданную рамку. Это удобнее ручного расчета, когда входные файлы имеют разные размеры.

Сам алгоритм масштабирования выбирается --vpp-resize. Доступны аппаратные VPL-варианты simple и advanced, разнообразные программные интерполяторы, libplacebo, FSR1 и, на поддерживаемой платформе, mfx_ai_superres. Последний — не универсальный улучшатель любого видео: его наличие и параметры зависят от VPL/драйвера и GPU, поэтому перед использованием нужно проверить поддержку.

--output-res 1920x-2 --vpp-resize spline64
--output-res 1920x1080 --vpp-resize algo=libplacebo-sinc,pl-radius=3.0,pl-antiring=0.5
--vpp-resize algo=mfx_ai_superres,superres-mode=sharpen,superres-algo=2

--vpp-resize-mode позволяет выбрать auto, lowpower или quality для соответствующих путей масштабирования. Lowpower ориентирован на аппаратный путь с низкими затратами, quality — на более качественную обработку. Реальная разница зависит от конкретного алгоритма; если явно выбран внешний OpenCL/libplacebo resizer, логика режима может отличаться от fixed-function resize.

Цветовое пространство и диапазон

Параметры --colormatrix, --colorprim, --transfer, --colorrange и --chromaloc описывают цвет в выходном bitstream. Значение auto удобно, когда входные метаданные достоверны и их нужно перенести. Но эти опции сами по себе не перекрашивают пиксели: если требуется реальная конверсия между матрицами или HDR/SDR, используется VPP-преобразование цвета.

--vpp-colorspace умеет выполнять конверсию, например BT.601 → BT.709, а также HDR-to-SDR tone mapping. Для сложной HDR-обработки доступен и libplacebo tone mapping. Разница принципиальна: сигнал можно либо только пометить метаданными, либо математически преобразовать. Ошибка, когда SDR-картинка просто маркируется как BT.2020/PQ без пересчета, не исправляется красивыми тегами.

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

HDR10, HDR10+ и Dolby Vision

Для статического HDR доступны mastering display и MaxCLL/MaxFALL. Их можно задавать либо копировать из входа, если reader поддерживает соответствующие metadata. Для HDR10+ предусмотрена работа с динамической информацией. В каждом случае важно различать перенос метаданных и tone mapping: копирование HDR metadata предполагает, что видеосигнал остается в соответствующем HDR-пространстве.

Dolby Vision поддерживается через --dolby-vision-profile и --dolby-vision-rpu. QSVEncC умеет интерливить RPU из файла или копировать его из входного HEVC, а для некоторых профилей автоматически настраивает необходимые VUI/служебные элементы. При этом вывод ограничен BL+RPU: enhancement layer в итог не формируется. Это существенное ограничение, которое нужно учитывать при переработке исходников Profile 7 и других многослойных вариантов.

Для соблюдения профильных ограничений Dolby Vision по bitrate/HRD разумно использовать режим с контролем битрейта и правильно задавать --max-bitrate/--vbv-bufsize. ICQ и CQP технически могут применяться, но сами по себе не гарантируют соответствие потолку потока. Если файл предназначен для строго заданной цепочки воспроизведения, формальные ограничения профиля важнее субъективного выбора качества.

При --dolby-vision-rpu copy необходимы корректные timestamps, потому что frames нужно сопоставить между decode и presentation order. Для raw elementary stream без временных меток аппаратный reader может не подойти; в таком случае документация предлагает попробовать software reader. Это хороший пример того, почему аппаратное декодирование всегда лучше — неверное правило.

Прожиг субтитров, логотипы и геометрия

--vpp-subburn используется, когда субтитры должны стать частью изображения. Для текстовых форматов важны шрифты, стиль и позиционирование, для графических — корректные timestamps и масштаб. Прожиг выполняется до кодирования, поэтому результат сразу влияет на распределение битов: мелкий контрастный текст — сложная область для encoder.

--vpp-delogo предназначен для удаления заданной области/маски логотипа в поддерживаемом формате. Есть также crop, pad, rotate, transform, overlay, lens correction, v360 и другие геометрические операции. Их разумно выполнять до масштабирования или после него в соответствии с фиксированным порядком VPP, а не полагаться на порядок аргументов в строке.

При сочетании crop и HDR/Dolby Vision отдельного внимания требует active area. Если физически убраны letterbox-полосы, связанные metadata могут нуждаться в корректировке. QSVEncC имеет параметры RPU для обнуления active-area offsets, но применять их следует только тогда, когда геометрия действительно изменилась соответствующим образом.

AI, OpenVINO и пользовательские шейдеры

В расширенной VPP-цепочке присутствуют фильтры, работающие через OpenVINO/ONNX, RIFE-интерполяция, Anime4K shader chain и libplacebo custom shader. Эти инструменты существенно отличаются от fixed-function QSV: они используют вычислительные ресурсы GPU, могут требовать моделей и способны стать главным узким местом всей операции. Быстрый hardware encoder не ускорит pipeline, если тяжелый фильтр обрабатывает кадры медленнее.

С ONNX-моделями важно использовать поддерживаемый manifest/каталог моделей и не подменять модель похожим файлом. Для GLSL/libplacebo нужно учитывать совместимость шейдера с реализацией и ожидаемым форматом входа. Если фильтр не дает видимого эффекта либо скорость постепенно падает, диагностика должна включать GPU memory, OpenCL/Vulkan backend и task profiling, а не только строку encoder fps.

Такие фильтры особенно плохо подходят для слепого копирования чужой командной строки. У пользователя могут отличаться GPU, драйвер, разрешение, формат поверхности и доступная VRAM. Начинать лучше с encode без тяжелого фильтра, затем добавлять по одному и сравнивать лог VPP.

SSIM, PSNR и VMAF

QSVEncC умеет рассчитывать SSIM и PSNR для encoded result. Это позволяет быстро получить техническую метрику относительно исходных кадров в рамках одного процесса. Метрики полезны для сравнения режимов при одинаковом источнике, но не заменяют визуальную проверку: высокий PSNR может предпочесть сглаженное изображение, тогда как субъективно пользователю важнее сохранение текстуры.

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

При включении SSIM/PSNR/VMAF --parallel отключается. Это логично: метрика должна сравнивать последовательность итоговых decoded frames с эталоном в общей временной шкале, что плохо сочетается с независимым file-split encode. Для корректного сравнения сначала определяют исследуемую настройку, затем запускают отдельные одинаковые тестовые отрезки.

Журнал, мониторинг и поиск узкого места

Обычный progress уже показывает fps, bitrate и загрузку, но QSVEncC имеет дополнительные средства profiling. --task-perf-monitor выводит время отдельных задач в конце лога. --vpp-perf-monitor измеряет время фильтров, однако сам замер снижает общую производительность, потому что программе приходится ожидать завершения операций для точного измерения.

--perf-monitor может собирать CPU usage по потокам, GPU load и clock, video encoder usage, заполнение очередей, память, чтение/запись диска, fps и bitrate. Интервал задается отдельно. Такие показатели полезнее общей цифры GPU 40%: аппаратный media engine, compute/OpenCL и copy engine — разные блоки, и один общий процент диспетчера задач не объясняет, где задерживается pipeline.

Если encoder загружен полностью, а CPU и VPP простаивают, дальнейшее ускорение требует другого режима/устройства или параллельности. Если encoder недогружен, но decoder упирается в предел, стоит проверить software decode или второй media block. Если VPP съедает большую часть времени, менять ICQ на CQP ради скорости может почти ничего не дать. Profiling нужен именно для отделения этих сценариев.

Практическая установка и запуск в Windows

Для работы QSV необходим корректный Intel Graphics Driver. После распаковки QSVEncC первое практическое действие — не длинный encode, а --check-hw и --check-features. Если QSV не обнаружен, переустановка или обновление драйвера Intel обычно полезнее перебора параметров кодирования: encoder не запустится, пока runtime не видит медиаблок.

В системе с несколькими GPU iGPU может быть отключено прошивкой или политикой энергосбережения. Если рассчитывается именно на интегрированный QSV, нужно убедиться, что устройство видно ОС. При наличии Arc можно выбрать дискретное устройство через --device. Номер лучше брать из --check-device, а не угадывать по порядку в Диспетчере устройств.

Для Avisynth/VapourSynth важна разрядность и наличие соответствующего runtime. Если путь содержит не-ASCII символы, QSVEncC по умолчанию работает в UTF-8; старые ANSI-скрипты при необходимости запускаются с настройкой process codepage. Подобные ошибки проявляются еще до QSV encode, поэтому их нужно отделять от проблем аппаратного драйвера.

Практическая установка и запуск в Linux

В Linux аппаратный QSV требует корректного Intel media driver и доступа пользователя к GPU-устройствам. Для типичных дистрибутивов пользователь добавляется в группы video и render, после чего требуется новый вход в сессию. Если этого не сделать, бинарник может быть установлен правильно, но доступ к device node будет запрещен.

OpenCL-фильтры дополнительно требуют рабочего OpenCL runtime. --check-clinfo помогает проверить его отдельно от encoder. Если QSV encode работает, а OpenCL VPP падает, это уже другой слой проблемы. Документация также описывает ситуации, когда отсутствует ожидаемая ссылка на libOpenCL.so; исправлять нужно библиотечное окружение, а не параметры ICQ.

AvisynthPlus, VapourSynth и OpenVINO нужны только для соответствующих функций. Не требуется устанавливать весь набор зависимостей на всякий случай. Минимальная система для обычного avhw/avsw encode проще, а дополнительные runtime добавляются по мере необходимости.

Практические команды

HEVC с сохранением всех аудиодорожек

Для обычного перехода H.264 → HEVC без требования к фиксированному размеру разумной стартовой точкой будет ICQ. Десятибитный вывод следует включать только на поддерживаемом GPU и при необходимости.

QSVEncC.exe --avhw -i input.mkv -c hevc --icq 23 --quality balanced --audio-copy -o output.mkv

После запуска проверяют, что в журнале действительно указан HEVC, нужный profile/depth и ожидаемый audio mux. Если драйвер изменил target usage или отключил настройку, это будет напечатано перед основным блоком.

AV1 на поддерживаемом Intel GPU

QSVEncC.exe --avhw -i input.mkv -c av1 --icq 25 --output-depth 10 --audio-copy -o output.mkv

Если команда сообщает, что AV1 encode недоступен, менять расширение файла или профиль бессмысленно: сначала нужно проверить --check-features. AV1 decode и AV1 encode — разные возможности, и наличие аппаратного декодирования не гарантирует аппаратное кодирование.

Интерлейсный MPEG-2 TS в progressive HEVC

QSVEncC.exe --avhw --interlace tff -i capture.ts -c hevc --icq 23 --vpp-deinterlace normal --audio-copy -o output.mkv

Ключевой момент здесь не сам HEVC, а корректный field order. Если источник BFF, нужно заменить TFF. Для сложных смешанных телезаписей простой deinterlace может быть не лучшим решением: RFF/IVTC/KFM выбираются по структуре материала.

Точный кадровый фрагмент

QSVEncC.exe --avhw -i input.mkv --trim 1500:4500 -c h264 --icq 22 --audio-codec aac -o clip.mp4

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

Сохранение дорожек и метаданных в MKV

QSVEncC.exe --avhw -i input.mkv -c hevc --icq 23 --colormatrix auto --transfer auto --colorprim auto --chromaloc auto --max-cll copy --master-display copy --audio-copy --audio-metadata copy --sub-copy --sub-metadata copy --data-copy --attachment-copy --chapter-copy -o output.mkv

Команда специально длинная, потому что сохранить всё состоит из отдельных решений. Для SDR-файла HDR-параметры не нужны. Для MP4 attachments могут быть бессмысленны. Практичнее хранить такую строку в сценарии или option file и убирать части, которые не относятся к конкретной коллекции.

Сложная подготовка в FFmpeg, encode в QSVEncC

ffmpeg -i input.mov -vf "scale=1920:1080" -an -pix_fmt yuv420p -f yuv4mpegpipe - | QSVEncC.exe --y4m -i - -c h264 --icq 22 -o output.mp4

Здесь внешняя программа формирует Y4M, а QSVEncC видит уже подготовленные кадры. Если нужно передавать одновременно audio, разумнее использовать NUT. У такой цепочки выше гибкость, но диагностика сложнее: ошибку нужно локализовать по обе стороны pipe.

Пакетная обработка

Так как QSVEncC управляется командной строкой, его удобно вызывать из PowerShell, batch, shell, Python и систем автоматизации. Главное правило пакетного сценария — не строить одну команду, предполагающую одинаковые дорожки и HDR у всех файлов. Лучше заранее определить классы исходников либо анализировать их перед запуском.

Для повторяемых наборов параметров предусмотрен --option-file. Это уменьшает длину командной строки и упрощает изменение профиля обработки. В option file разумно хранить только стабильные параметры, а input/output, trim и специфические для файла metadata оставлять в вызывающем сценарии.

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

Почему драйвер меняет значения

Строки вида value changed ... by driver — важная особенность QSV. QSVEncC запрашивает конфигурацию, затем драйвер проверяет ее на соответствие аппаратному encoder. Он может уменьшить число references, заменить target usage, выключить B-pyramid или изменить QP limit. Такое сообщение не обязательно означает ошибку; это фиксация реально принятой конфигурации.

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

Это также объясняет, почему чужие идеальные параметры плохо переносятся между UHD Graphics и Arc. Названия опций одинаковы, но backend реализует их по-разному. Самый надежный переносимый рецепт — короткая базовая команда, feature check и добавление расширенных опций только после подтверждения поддержки.

Типичные ошибки и способы решения

QSV не найден

Начать следует с --check-device, --check-hw и --check-environment. Если устройство отсутствует, проблема находится ниже уровня кодека: драйвер, отключенный iGPU, права на Linux или неподходящее окружение. Пытаться лечить такой случай изменением --icq или GOP бессмысленно.

Опция отключается как unsupported

Сначала это нужно воспринимать как диагностическую информацию. Выполните --check-features для того же device и codec. Если функция действительно отсутствует, уберите ее или выберите другой режим. --fallback-rc позволяет откатиться к поддерживаемому rate control, но не превращает аппаратно отсутствующую функцию в доступную.

Encode зависает или появляется GPU hang

Нужно сократить команду до минимальной: input, codec и простой ICQ. Если она работает, добавлять фильтры и advanced options по одному. Если минимальная команда тоже падает, проверить драйвер и другой reader. GPU hang часто связан не с контейнером вывода, а с конкретным сочетанием драйвера, режима encoder и параметров. Журнал перед зависанием важнее общего сообщения в конце.

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

Попробуйте --avsw. Если software decode проходит, проблема локализована в decode path или формате входа, а не в encoder. Для некоторых raw/нестандартных потоков программный путь также удобнее из-за timestamps и форматов поверхностей. Использовать CPU decode вполне нормально, если это делает pipeline стабильнее и CPU не является узким местом.

Не находится аудиодорожка

Увеличьте анализ входа и probe size, особенно для TS. Проверьте, что reader avhw/avsw действительно видит дорожку. Если copy дает ошибку, попробуйте аудиоперекодирование. Для нестандартного stream-id полезно явно выбрать дорожку, а не полагаться на порядок.

Рассинхронизация видео и аудио

Проверьте исходные timestamps, VFR, RFF и реальную частоту кадров. Для проблемного CFR-потока может помочь --avsync forcecfr, для нормального VFR — --avsync vfr или passthrough. Если используется trim, убедитесь, что выбранный avsync с ним совместим. Нельзя надежно исправить timestamp-проблему изменением audio bitrate.

Parallel не включается

Проверьте ограничения: pipe, non-seekable input, trim, metrics, subburn, timecode и dynamic RC автоматически отключают file-split parallel. В логе будет видно фактическое поведение. Если задача содержит одну из несовместимых функций, нужно либо отказаться от parallel, либо изменить workflow, например выполнить измерение качества отдельным проходом.

OpenCL-фильтр падает

Проверьте --check-clinfo. Если OpenCL runtime отсутствует, QSV encode при этом может продолжать работать, потому что это разные подсистемы. В Linux проверьте группу render и установленный runtime; в Windows — драйвер Intel. Если проблема только в одном фильтре, замените его аппаратной или CPU-альтернативой.

Слишком высокая загрузка памяти

Тяжелые VPP, AI/ONNX, high-resolution 10-bit и parallel быстро увеличивают число поверхностей. Уменьшите parallel count, async depth или отключите наиболее тяжелый фильтр. Не используйте --parallel-force-large-memory-filters, если уже наблюдается нехватка VRAM: эта опция снимает защитное ограничение, а не экономит память.

Файл создается, но профиль не тот

Смотрите блок Output и сообщения драйвера. Профиль/level могут выбираться автоматически по resolution, fps и функциям. Если целевое устройство требует конкретный level, задайте его только в пределах реальной совместимости параметров. Слишком низкий level нельзя форсировать при битрейте и разрешении, которые превышают его ограничения.

Проверка функций на разных поколениях Intel

Сравнивать поколения удобнее не по рекламным названиям GPU, а через фактический вывод --check-features. Он показывает таблицу для текущего codec и rate-control modes. На одном устройстве HEVC может иметь 10-bit, lookahead и B-pyramid, на другом часть строк будет недоступна. Для VP9 и AV1 разница между поколениями еще заметнее.

При обновлении драйвера feature table тоже может измениться. Это не обязательно означает регрессию QSVEncC: часть возможностей объявляет именно драйвер. Если после обновления исчез параметр, полезно сохранить результаты --check-features до и после и сравнить их вместе с журналом окружения.

В mixed-GPU системе нужно запускать проверку для того device, который будет кодировать. Иначе легко посмотреть возможности iGPU, а encode отправить на Arc или наоборот. Привязка --device делает тест воспроизводимым.

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

Программа	Лучше подходит для	Главное ограничение
QSVEncC	Тонкой настройки Intel Quick Sync, VPP, многодорожечного транскодирования и сценариев командной строки	Требует понимания CLI и возможностей конкретного Intel GPU
FFmpeg с QSV	Сложных filter graph, сетевых потоков, нестандартного mux/demux и универсальных автоматизированных цепочек	QSV-настройки распределены между синтаксисом FFmpeg и backend Intel, поэтому конфигурация менее специализирована
HandBrake	Быстрой повседневной конвертации с готовыми профилями и понятным выбором аппаратного encoder	Меньше низкоуровневых QSV/VPP-параметров и сложнее воспроизвести редкие специализированные цепочки
StaxRip	Сборки многокомпонентного encode через графический интерфейс с QSVEncC и другими encoder	Результат зависит от внешних инструментов и шаблонов, а диагностика проходит через несколько уровней
NVEncC	Похожей специализированной CLI-обработки при наличии NVIDIA GPU	Использует NVIDIA NVENC/NVDEC и не дает доступа к Intel QSV
VCEEncC	Похожей специализированной CLI-обработки на AMD GPU	Ориентирован на AMD AMF, поэтому аппаратные режимы и ограничения отличаются

Практический выбор определяется не только удобством интерфейса. Если задача строится вокруг Intel GPU, нужны --check-features, аппаратные режимы QSV, точный контроль VPP и возможность включать/выключать функции драйвера, QSVEncC дает наиболее прямой специализированный доступ. FFmpeg удобнее там, где основной сложностью является filter graph, протоколы или экзотический контейнер. HandBrake проще для типовых файлов. StaxRip полезен тем, кто хочет собирать QSVEncC-команду через GUI и одновременно пользоваться другими инструментами. NVEncC и VCEEncC становятся прямой альтернативой при другой марке GPU, но перенос настроек между ними не является один-к-одному эквивалентным.

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

Программа хорошо подходит для повторяемых домашних и рабочих pipelines: массового перевода архива в HEVC/AV1, обработки телевизионных TS с deinterlace, подготовки нескольких аудио и subtitle tracks, HDR metadata passthrough, автоматических скриптов и исследований возможностей Intel media engine. Сильная сторона — прозрачность: почти каждый важный этап можно увидеть в журнале и зафиксировать параметром.

Она менее удобна, если пользователь ожидает перетаскивание файла мышью, визуальный предпросмотр фильтров и готовый профиль для телефона без понимания кодека. Командная строка требует дисциплины имен файлов и параметров, а расширенная VPP-цепочка — проверки на коротком фрагменте. Это не недостаток hardware encoder как такового, а цена точного управления.

Оптимальная стратегия — начинать с минимальной рабочей команды, подтвердить аппаратные возможности, затем добавлять rate control, depth/profile, аудио/субтитры и VPP по одному смысловому блоку. Такой подход быстрее приводит к надежному шаблону, чем строка из нескольких десятков опций, происхождение которых неизвестно.

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

Как выбирать между ICQ и QVBR

ICQ удобнее, когда размер файла не фиксирован и качество должно оставаться приблизительно одинаковым на материалах разной сложности. QVBR полезнее, когда нужен ориентир по bitrate и одновременно есть требование не ухудшать простые сцены из-за жесткой CBR-логики. Для двух режимов нет универсальных эквивалентных чисел: значение ICQ и quality-параметр QVBR интерпретируются драйвером, поэтому сравнение проводят на одинаковом отрезке и одном target usage.

Почему нельзя оценивать encode только по fps

Высокий fps может означать удачную аппаратную конфигурацию, но не говорит о качестве, правильности цвета, синхронизации и сохранности дорожек. Кроме того, pipeline способен быть ограничен decoder, VPP или диском. Итоговый критерий — корректный файл с нужными параметрами; скорость сравнивают уже после того, как эти параметры совпадают.

Когда software decode быстрее

Аппаратный decode обычно экономит CPU, однако при parallel encode или при необходимости часто копировать поверхности между разными устройствами hardware path способен стать узким местом. Документация QSVEncC отдельно отмечает, что при нескольких media units и сильном CPU software decode иногда дает более высокую общую производительность. Проверять это нужно итоговым временем при одинаковых encode/VPP настройках.

Как читать первые строки лога

Сначала смотрят OS/CPU/GPU, затем Media SDK/VPL и номер выбранного устройства, далее Buffer Memory, Input Info и VPP. Только после этого анализируют Output и Encode Mode. Если уже в Input Info вместо ожидаемого avqsv появился avsw, значит аппаратный decode не используется. Если Output имеет другую глубину или profile, проблема находится до начала собственно прогресса.

Работа с HDR без случайной порчи сигнала

При HDR-перекодировании безопасный порядок действий начинается с определения входных primaries, transfer, matrix и mastering metadata. Если задача — оставить HDR, видео должно сохранять подходящую transfer function и цветовое пространство, а metadata копируется или задается осознанно. Если задача — получить SDR, нужен tone mapping; простое удаление HDR-тегов дает темную или выцветшую картинку.

При ресайзе HDR сам по себе не обязан менять цветовое пространство, но разные filter backend могут работать во внутреннем RGB/YUV и с разной точностью. Поэтому после добавления libplacebo/OpenCL-фильтра стоит проверить, что output metadata соответствует фактическому результату и в логе нет неожиданных конверсий.

Динамические метаданные HDR10+/Dolby Vision нужно рассматривать как отдельный поток информации, синхронизированный с кадрами. Обрезка, изменение временной структуры, decimation и интерполяция кадров могут нарушить исходное соответствие. Чем сильнее меняется timeline, тем менее безопасно безусловное copy динамической metadata.

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

1. Проверить устройство командами --check-device и --check-hw.
2. Проверить codec/rate control через --check-features.
3. Запустить короткую команду без фильтров и без копирования лишних дорожек.
4. Добавить нужную глубину цвета и profile, снова проверить фактический Output.
5. Добавить аудио и subtitle mux, убедиться в корректной длительности.
6. Добавлять VPP по одному смысловому блоку, отслеживая скорость и память.
7. Только после стабильного одиночного encode включать parallel или Hyper Mode.

Такой порядок отделяет ошибку драйвера от проблемы reader, muxer и фильтра. Если сразу включить AV1 10-bit, несколько тяжелых VPP, Dolby Vision RPU, subburn и parallel, итоговое сообщение об ошибке почти не дает информации, какой компонент был причиной.

Параметры, которые часто копируют без необходимости

--quality best не обязан быть лучшим выбором для каждой задачи: поддерживаемая ступень может быть заменена драйвером, а прирост качества относительно balanced зависит от codec/GPU. --async-depth не нужно автоматически ставить максимально. Большое число references/B-frames тоже не является бесплатным улучшением и способно быть урезано аппаратным backend.

Аналогично, --max-bitrate и --vbv-bufsize нужны, когда действительно есть ограничение по потоку или стандарту. В ICQ для обычного архива слишком жесткий потолок может мешать режиму поддерживать выбранное качество на сложных сценах. Наличие опции в примере для Blu-ray/Dolby Vision не делает ее обязательной для всех HEVC-файлов.

Цветовые теги нельзя переносить из чужого пресета. BT.2020/PQ, BT.709 и full/limited — свойства конкретного сигнала. Ошибочная явная установка хуже auto, если входные metadata корректны.

Часто задаваемые вопросы

Нужно ли обязательно использовать --avhw?

Нет. Аппаратное декодирование полезно, но software decode через --avsw остается полноценным вариантом. Он нужен для неподдерживаемого decoder, необычного формата, некоторых сценариев с timestamps и ситуаций, когда CPU decode лучше балансирует parallel pipeline.

Можно ли использовать QSVEncC только как фильтр?

Да. -c raw выводит необжатые кадры после чтения и VPP, а формат вывода можно согласовать с внешним процессом, например через Y4M/NUT. Это позволяет использовать фильтры QSVEncC перед другим encoder.

Почему --check-features важнее списка функций в статье?

Потому что таблица строится по конкретному GPU и драйверу пользователя. Статья может перечислить все поддерживаемые QSVEncC интерфейсы, но аппаратная реализация отличается между поколениями.

Нужно ли всегда сохранять все metadata?

Нет. Языки, названия дорожек и главы обычно полезны, а технические теги нужно сопоставлять с тем, что изменилось. После tone mapping нельзя слепо сохранять HDR-теги исходника; после crop могут измениться active-area данные; после аудиоперекодирования codec-specific metadata может стать неактуальной.

Почему output bitrate отличается от заданного VBR?

VBR — не обещание побитно попасть в число на каждом коротком отрезке. На результат влияют сложность сцены, QP limits, max bitrate, buffer и решения драйвера. Если драйвер поднял минимальный QP, он может физически не расходовать столько битов на простой материал, сколько просит target.

Что означает низкая общая GPU load при высокой скорости?

Fixed-function encoder является отдельным блоком. Общая загрузка 3D/compute может быть низкой, пока media engine занят почти полностью. Смотрите специализированные показатели video encoder и лог QSVEncC, а не только общий процент GPU.

Рабочий подход к выбору фильтров

Для плохого interlace-сигнала сначала решается временная структура: deinterlace/IVTC. Затем — шум, если он мешает кодированию. После этого — resize, и только затем умеренная резкость или detail enhancement. Такой порядок согласуется с общей логикой pipeline: нет смысла сначала усиливать шум резкостью, а потом пытаться его убрать.

Deband нужен для градиентов с полосами, но добавление зерна после deband увеличивает энтропию и bitrate. Если итоговый encode очень ограничен по потоку, слишком сильный grain сведет часть пользы на нет. С другой стороны, полное удаление естественного зерна ради маленького файла может визуально ухудшить материал сильнее, чем умеренно больший bitrate.

AI-upscale и frame interpolation стоит оценивать отдельно от encoder. Они создают новые детали/кадры, которые потом приходится кодировать. Если после RIFE fps удваивается, объем работы encoder и mux тоже растет. Поэтому сравнивать скорость до/после только по encoder fps некорректно — изменилась сама задача.

Надежные шаблоны для автоматизации

Хороший шаблон разделяет постоянные и переменные параметры. В option file можно вынести -c hevc, ICQ, target usage и выбранные VPP. В скрипте остаются input, output, выбор дорожек и условия HDR. Для файлов с Dolby Vision или HDR10+ создается отдельная ветка, потому что динамические metadata нельзя безопасно добавлять в SDR-шаблон.

Имена выходных файлов стоит формировать до запуска и не менять расширение случайно: расширение участвует в автоматическом выборе muxer. Если нужен Matroska, скрипт должен явно создать .mkv, а не наследовать .mp4 от исходника. При необходимости можно добавить --output-format, но проще не создавать противоречие между именем и форматом.

Для очереди из сотен файлов полезно сохранять команду и лог каждого задания. Тогда через месяцы можно объяснить, почему конкретный файл получился 8-bit, почему B-pyramid отключен или какой GPU был выбран. Воспроизводимость — одно из главных преимуществ CLI, и ее стоит сохранять вместе с результатом.

Краткий справочник по логике параметров

Задача	Основной параметр	Что проверить
Выбор GPU	--device	--check-device и строку GPU Info
Аппаратное чтение	--avhw	Input Info и поддерживаемый decode codec
Программное чтение	--avsw	Нагрузку CPU и формат кадров
Качество без фиксированного размера	--icq	Фактический rate control и target usage
Ограничение потока	--vbr/--cbr/--qvbr	Max bitrate, VBV и требования профиля
10-битный вывод	--output-depth 10	Codec/profile и feature table GPU
Изменение размера	--output-res, --vpp-resize	Aspect ratio и выбранный алгоритм VPP
Деинтерлейс	--vpp-deinterlace и альтернативы	TFF/BFF, RFF, итоговый frame rate
Копирование аудио	--audio-copy	Совместимость codec с контейнером
Копирование субтитров	--sub-copy	Формат subtitle и поддержку muxer
Кадровая нарезка	--trim	Audio sync, главы и ограничения parallel
Параллельность	--parallel	Seekable input и несовместимые функции
Диагностика фильтров	--vpp-perf-monitor	Что profiling сам замедляет процесс
Диагностика системы	--perf-monitor	Encoder, GPU clock, CPU, I/O и очереди

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

Настройка H.264/AVC в QSVEncC

H.264 остается полезным вариантом, когда приоритетом является совместимость с телевизорами, медиаплеерами, браузерными устройствами и программами монтажа. В QSVEncC H.264 выбирается через -c h264. Для обычного файлового транскодирования достаточно начать с ICQ и не задавать вручную десятки структурных параметров. После запуска журнал покажет профиль, level, число references, B-кадры и фактический target usage.

Профиль High обычно уместен для современного progressive-видео 4:2:0, но конкретный профиль следует выбирать под требования воспроизведения. Если устройство назначения старое, более консервативные настройки могут оказаться важнее небольшого выигрыша в сжатии. Level должен соответствовать разрешению, частоте кадров, bitrate и reference structure. Значение auto снижает риск задать level, который формально недостаточен для выбранного режима.

Для H.264 доступны специфические опции, включая trellis и Blu-ray-oriented output. Их не следует добавлять в общий пресет только потому, что они существуют. Blu-ray-ограничения нужны при подготовке совместимого потока, а trellis имеет смысл лишь там, где его действительно поддерживает аппаратный backend. Если --check-features показывает отсутствие функции, QSVEncC не сможет получить ее из другого profile.

H.264 особенно чувствителен к чрезмерному усложнению GOP в старых декодерах. Большое число references и B-frames может повысить эффективность на поддерживаемой платформе, но также увеличить требования к декодированию. Для универсального файла разумнее оставить автоматический/умеренный набор и оптимизировать прежде всего ICQ, target usage и разрешение.

QSVEncC.exe --avhw -i input.mkv -c h264 --icq 21 --quality balanced --audio-copy -o output.mp4

Настройка HEVC

HEVC выбирается через -c hevc и часто применяется для уменьшения размера архива относительно H.264 при сопоставимом субъективном качестве. Для 10-bit нужен --output-depth 10 и поддерживаемый профиль, обычно main10 для 4:2:0. Само увеличение разрядности не гарантирует меньший файл, но помогает сохранить градиенты и является типичной основой HDR-потоков.

В HEVC аппаратный backend может иметь свои ограничения по B-frames, SAO, CTU и другим coding tools. QSVEncC умеет запросить эти параметры, но драйвер имеет право отключить их или скорректировать значения. Поэтому перенос команды, созданной для Arc, на старую UHD Graphics нужно начинать с --check-features, а не с попытки подавить предупреждения.

Для HDR HEVC особенно важно согласование bit depth, transfer/primaries/matrix, mastering metadata и контейнера. Если исходник HDR10 перекодируется в HEVC 10-bit без tone mapping, цветовые metadata должны отражать сохраненный HDR-сигнал. Если выполняется SDR-конверсия, нужно изменить и пиксели, и их описание. Простое --output-depth 10 само по себе не делает файл HDR.

При создании файлов с ограниченным максимумом потока VBR/CBR/QVBR и VBV дают более предсказуемое соответствие техническим требованиям, чем CQP/ICQ. Для домашнего архива, наоборот, ICQ часто проще: программа распределяет битрейт по сложности сцен, а пользователь регулирует качество одним параметром.

QSVEncC.exe --avhw -i input.mkv -c hevc --icq 23 --output-depth 10 --audio-copy --sub-copy --chapter-copy -o output.mkv

Настройка AV1

AV1 в QSVEncC предназначен для Intel GPU с соответствующим аппаратным encoder. Проверять поддержку нужно отдельно от decode: наличие AV1 playback не означает, что устройство умеет создавать AV1. Команда --check-features показывает не только сам codec, но и доступные режимы rate control и связанные coding tools.

Для файлового AV1 логичной стартовой точкой остается ICQ. На подходящей платформе можно добавлять 10-bit, lookahead и ExtBRC, но только после подтверждения feature table. AV1 часто используется с более длинными GOP, однако QSVEncC сам учитывает требования своего backend; ручная установка чрезмерно длинной структуры не должна быть первым шагом настройки.

AV1 полезно тестировать на коротких репрезентативных фрагментах: темных сценах, зерне, быстром движении, анимационных контурах и градиентах. Если сравниваются HEVC и AV1, должны совпадать разрешение, VPP, bit depth и метод оценки. Сравнение AV1 ICQ 30 против HEVC CQP 22 не показывает превосходство codec, потому что одновременно изменены rate-control semantics.

При mux в MP4/MKV нужно учитывать поддержку AV1 конечным устройством. Современный codec может быть технически эффективнее, но бесполезен, если телевизор или монтажная программа его не декодирует. Поэтому формат выбирают по всей цепочке использования, а не только по способности GPU выполнить encode.

VP9 и MPEG-2

VP9 и MPEG-2 присутствуют среди аппаратных вариантов QSVEncC, но используются заметно реже H.264/HEVC/AV1. VP9 может быть полезен в конкретной инфраструктуре, где он уже принят, однако набор rate-control modes и bit-depth зависит от устройства. В старых поколениях Intel поддержка VP9 encode существенно отличалась, поэтому feature check обязателен.

MPEG-2 актуален главным образом для совместимости с устоявшимися системами и отдельными broadcast/workflow. С точки зрения эффективности сжатия он уступает современным codec, но может быть нужен именно из-за требований системы назначения. QSVEncC позволяет использовать тот же подход к reader, mux, audio и части VPP, меняя только codec и специфичные для него параметры.

Если исходник MPEG-2 interlaced, наличие MPEG-2 на входе не означает необходимость MPEG-2 на выходе. Частый сценарий — аппаратно прочитать MPEG-2, выполнить deinterlace и перекодировать в HEVC/AV1. Отдельно проверяется, справляется ли выбранный GPU с hardware decode данного транспортного потока; при проблемах всегда остается avsw.

Профили, level, tier и совместимость

Profile описывает набор coding features, level — пределы по разрешению, частоте, bitrate и другим ресурсам, tier для некоторых codec уточняет допустимый bitrate. Эти поля не являются независимыми ползунками качества. Повышение level не улучшает изображение; оно лишь разрешает более высокие параметры. Выбирать level выше необходимого без причины так же бессмысленно, как искусственно занижать его до несовместимого значения.

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

В 10-bit HEVC типичен main10, но YUV 4:4:4 может требовать другой profile и далеко не всегда поддерживается hardware encoder. То же относится к высоким частотам и разрешениям. QSVEncC предоставляет интерфейс к возможностям драйвера, а не программный codec, который обязательно реализует полный профильный набор на любой видеокарте.

Работа с несколькими видеодорожками

Контейнер может содержать основной фильм, альтернативный угол, низкоразрешенную копию или служебный видеопоток. --video-track выбирает дорожку по разрешению: положительные значения идут от самой большой, отрицательные — от самой маленькой. Это удобно, если stream IDs меняются между файлами, но логика основная дорожка — самая большая сохраняется.

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

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

Глубокая работа с аудиодорожками

Нумерация аудио в QSVEncC относится к аудиодорожкам, а не обязательно к глобальному stream index контейнера. Это удобно для команд вида --audio-copy 1,2, но требует внимательно читать найденный состав входа. При выборе по языку качество metadata становится критичным: дорожка без language tag не попадет в правило, рассчитанное на eng или jpn.

Исключения через ! упрощают схему копировать всё, кроме комментария. Для библиотеки с разным порядком дорожек надежнее язык и disposition, если они размечены правильно. Если разметка хаотична, автоматизация должна сначала анализировать container metadata и только затем строить параметры QSVEncC.

Перекодирование аудио имеет смысл, когда codec не поддерживается целевым контейнером или устройством, либо нужен единый формат библиотеки. Для речи и стерео нет необходимости использовать настройки многоканального кино; для 5.1/7.1 нельзя бездумно включать downmix. QSVEncC позволяет управлять каналами и bitrate, но правильное решение определяется содержимым и назначением.

Если нужно сохранить Atmos/объектные данные, прямой copy безопаснее перекодирования, если контейнер назначения их поддерживает. Обычный AAC/Opus encode не сохраняет специфические расширения исходного Dolby-потока как эквивалентную объектную сцену.

Disposition и язык дорожек

В многодорожечном файле важно не только наличие потоков, но и то, какая дорожка помечена default, forced или имеет иной disposition. QSVEncC позволяет управлять такими атрибутами для mux. При конвертации архива стоит проверить, не стало ли описание режиссера дорожкой по умолчанию после удаления первой звуковой дорожки.

Для субтитров forced имеет особое значение: плеер может показывать только переводы надписей/иностранной речи. Если forced flag утрачен, пользователь либо не увидит нужные реплики, либо будет вынужден включать полные субтитры. Поэтому при selective copy metadata дорожек заслуживает такой же проверки, как codec.

Фиксированный порядок VPP на практике

Поскольку QSVEncC не строит произвольный filter graph из порядка аргументов, полезно мысленно разбить VPP на стадии. Сначала приводятся цвет и HDR, затем решается временная структура interlace/RFF, потом уменьшается шум, после этого меняется размер и восстанавливаются детали, а ближе к концу выполняются геометрические и декоративные операции. Прожиг субтитров должен происходить в ожидаемом масштабе, иначе текст может оказаться слишком мелким или размытым.

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

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

AFS, KFM, RFF и сложные телевизионные источники

Записи цифрового телевидения могут сочетать interlace, repeat field flags, телесинированный материал, вставки с другой частотой и поврежденные timestamps. В таких файлах простой bob/deinterlace часто делает формально progressive-видео, но не обязательно сохраняет исходную кинематографическую частоту. AFS/KFM/IVTC предназначены для более сложного анализа временной структуры.

Перед массовой обработкой стоит взять несколько минут с типичными переходами: титры, панорамы, вставки студии, реклама, анимация. Проверяются плавность, дубли, пропуски и длительность. Если фильтр меняет число кадров, audio sync и VFR/CFR становятся частью задачи, а не отдельной постобработкой.

RFF требует особой осторожности. В некоторых режимах фильтра определенные сочетания RFF могут не поддерживаться полностью. Если после смены режима длительность неожиданно меняется, нужно вернуться к анализу field/timestamp, а не компенсировать расхождение ручным ускорением аудио.

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

При изменении размера важно различать storage resolution и display aspect ratio. Например, старый anamorphic источник может иметь пиксельное соотношение сторон, из-за которого 1440×1080 отображается как 16:9. Простое изменение width/height без учета SAR способно растянуть картинку. QSVEncC позволяет задавать/переносить SAR, а --output-res умеет сохранять aspect ratio при вычислении второй стороны.

Если нужно вписать изображение в фиксированный холст без искажения, используют сочетание resize и pad. Если нужно заполнить кадр с обрезкой краев — resize и crop. Эти две операции дают визуально разные результаты, поэтому сделать 1920×1080 недостаточно как постановка задачи: нужно определить, можно ли обрезать исходник и допустимы ли поля.

Downscale обычно менее требователен к алгоритму, чем сильный upscale, но тонкие линии и текст могут заметно отличаться. Для огромных библиотек аппаратный simple/advanced может быть оправдан скоростью; для мастер-файлов можно выбрать более качественный OpenCL/libplacebo resizer. Нельзя переносить оценку одного алгоритма с 4K→1080p на 480p→4K.

Deband, grain и компрессия градиентов

Banding часто появляется в небе, тенях, анимационных заливках и после предыдущего сжатия. Deband сглаживает ступени, но способен убрать и реальные слабоконтрастные детали. Многие deband-фильтры добавляют зерно/dither, чтобы скрыть повторное квантование. Это визуально помогает градиентам, но увеличивает сложность для encoder.

Если целевой bitrate очень низкий, сильное искусственное зерно может быть уничтожено codec или отнять биты у контуров. Если bitrate достаточный, легкое зерно помогает избежать пластика. Поэтому denoise → deband → grain нужно настраивать как единую стратегию, а не независимые галочки.

Динамический rate control

QSVEncC поддерживает сценарии, где rate-control параметры меняются по участкам. Это полезно, если разные главы или диапазоны требуют различного bitrate/quality. Такой режим усложняет воспроизводимость и несовместим с file-split parallel, потому что границы и состояние rate control должны согласовываться с общей временной шкалой.

Если цель — просто повысить качество одной сложной сцены, сначала стоит проверить, справляется ли ICQ/QVBR автоматически. Dynamic RC оправдан, когда есть осмысленная внешняя причина для разных ограничений, а не как замена нормально настроенному quality-based режиму.

Низкая задержка и потоковые сценарии

Опция low latency и ограниченные GOP/B-frame структуры нужны для realtime-сценариев, где кадр должен быстро пройти encode/decode. Уменьшение задержки обычно сокращает возможности будущего анализа и межкадрового предсказания, поэтому это компромисс с эффективностью сжатия. Для офлайн-архива low latency обычно не дает преимущества.

При live/pipe обработке важна устойчивость всей цепочки: reader должен отдавать timestamps, audio/video нужно mux без накопления огромных буферов, а encoder не должен использовать функции, требующие перемотки входа. Невозможность --parallel на обычном pipe — следствие этой архитектуры.

Option file как часть воспроизводимого профиля

Длинную команду трудно читать и поддерживать. --option-file позволяет вынести стабильные параметры в текстовый профиль: codec, ICQ, target usage, VPP и правила дорожек. Для разных задач можно иметь профили HEVC archive, AV1 archive, TV deinterlace и SDR proxy, но названия должны отражать назначение, а не обещать универсальное качество.

Преимущество option file — возможность version control и сравнения изменений. Если после обновления профиля файлы стали отличаться, можно увидеть, какая строка добавлена. Input/output, одноразовый trim и специфические HDR/RPU пути лучше оставлять вне общего файла, чтобы случайно не применить их к чужому источнику.

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

Если опция отсутствует даже в справке/option list текущей сборки, это уровень QSVEncC. Если опция есть, но --check-features показывает x/unsupported, это уровень устройства или драйвера. Если feature заявлена как доступная, но encode падает только на конкретном сочетании параметров, возможна ошибка драйвера, приложения или специфического bitstream. Такое разделение сильно ускоряет диагностику.

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

Что проверять после завершения encode

Успешный exit code означает, что процесс завершился, но не заменяет проверку результата. Сначала сравнивают длительность и число дорожек, затем codec/profile/depth/resolution/fps, audio languages и subtitle dispositions. Для HDR дополнительно проверяют color metadata и динамические данные, если они должны были сохраниться.

На визуальном контроле полезны первые секунды, места seek, сцены после склейки/trim, быстрые панорамы, темные градиенты, мелкий текст и финальные кадры. Ошибки timestamp часто проявляются около начала/конца, а дефекты deinterlace — на движении. Если файл создается для конкретного устройства, финальная проверка должна включать воспроизведение именно на нем.

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

Итоговая схема настройки

Надежная конфигурация QSVEncC строится снизу вверх. Сначала устройство и driver, затем reader/decode, потом codec и rate control, после этого profile/depth/GOP, далее дорожки и mux, и только затем VPP, HDR и parallel. Каждый следующий слой добавляется к уже рабочему предыдущему.

Такой порядок особенно важен для Intel QSV, где доступность функции определяется конкретным hardware/driver. Он позволяет пользоваться сильной стороной QSVEncC — подробным контролем — без превращения командной строки в набор случайных флагов. В результате получается не просто быстрый encode, а воспроизводимый процесс, который можно объяснить по журналу и повторить на следующем файле.