x265 позволяет кодировать видео в H.265/HEVC с точной настройкой качества, битрейта, глубины цвета, структуры GOP, многопоточности и служебных метаданных, получая на выходе сырой HEVC-поток из YUV- или Y4M-источника.

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

У x265 нет встроенного контейнерного мультиплексора и привычного окна с дорожками, фильтрами и кнопкой экспорта. CLI принимает подготовленные кадры в YUV или Y4M и записывает элементарный HEVC-битстрим, поэтому декодирование исходного MP4/MKV, масштабирование, обработка звука, субтитры и упаковка результата в контейнер обычно выполняются соседними инструментами рабочего процесса.

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

x265 решает узкую, но сложную задачу: превращает последовательность несжатых видеокадров в поток H.265/HEVC. Энкодер анализирует движение, выбирает разбиение изображения на блоки, предсказывает содержимое кадров, вычисляет остаток, квантует коэффициенты, формирует структуру ссылочных кадров и распределяет биты согласно выбранному режиму управления скоростью потока. Пользователь управляет этими решениями либо крупными пресетами, либо отдельными параметрами.

Это принципиально отличает x265 от универсального конвертера. У него нет задачи открыть любой ролик и сохранить в другой формат. Если исходник находится в MP4, MOV, MKV, MPEG-TS или другом контейнере, его сначала нужно декодировать до подходящей кадровой последовательности или передать через канал как Y4M. Аналогично, файл, полученный непосредственно от x265, не содержит аудиодорожек, глав, вложений или субтитров: это только HEVC-видео.

При этом отсутствие контейнерного слоя даёт точный контроль над самим кодированием. Можно отдельно выбрать режим CRF, ABR или фиксированный QP, ограничить VBV, задать структуру ключевых и B-кадров, выбрать профиль, глубину 8/10/12 бит, управлять психовизуальной оптимизацией, адаптивным квантованием и многопоточностью, передать HDR-метаданные и сохранить статистику. Именно эти параметры определяют поведение x265 как энкодера.

Как читать сообщения в консоли

При запуске x265 выводит несколько групп служебных строк. В начале обычно показываются версия HEVC-энкодера, сведения о сборке и обнаруженные SIMD-возможности процессора. Далее следуют профиль и уровень, число потоков, настройки Coding Tree и Transform Unit, метод оценки движения, параметры ключевых кадров, lookahead, B-кадров, адаптивного квантования и rate control. Затем появляется прогресс, а после завершения — статистика по типам кадров и итоговая скорость кодирования.

Эти строки полезны как проверка фактически применённых параметров. Если ожидался 10-битный Main 10, а в начале лога указан Main, это повод проверить разрядность сборки, --output-depth и --profile. Если ожидался определённый режим CRF, его удобно сопоставить со строкой Rate Control. Для автоматизации можно уменьшить объём консольного вывода или, наоборот, включить более подробный уровень логирования.

Синтаксис запуска и порядок параметров

Базовая форма команды выглядит как x265 [options] infile [-o] outfile. Входной файл можно указать позиционным аргументом или через --input, а выходной — вторым позиционным аргументом или через -o/--output. Для простого Y4M-файла достаточно задать качество, пресет и имя результата:

x265 --preset medium --crf 24 input.y4m -o output.hevc

Y4M удобен тем, что заголовок потока содержит базовые сведения о геометрии и частоте кадров. С сырым YUV таких метаданных нет, поэтому их требуется описать явно. Для Full HD с частотой 24000/1001 команда может выглядеть так:

x265 --input-res 1920x1080 --fps 24000/1001 --input-csp i420 --input-depth 8 --crf 24 input.yuv -o output.hevc

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

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

Почему порядок всё же стоит держать аккуратным

Хотя CLI применяет параметры пресета и tune до остальных настроек независимо от их позиции, человеку проще читать команду, когда она собрана предсказуемо. Удобная практика — сначала входные параметры, затем --preset и --tune, далее rate control, затем GOP и инструменты анализа, в конце профиль, VUI/HDR и имя выхода. Такой порядок не является требованием энкодера, но заметно облегчает поиск противоречий.

Например, команда с --preset slow, --tune grain и ручным --psy-rd должна восприниматься как slow плюс набор изменений для grain, после которых вручную задано собственное значение psy-rd. Если параметры разбросаны по строке, тот же результат получится технически, но разбирать намерение автора существенно сложнее.

Вход Y4M: самый удобный формат для CLI

Y4M, или YUV4MPEG2, представляет собой простой поток несжатых кадров с текстовым заголовком. Для x265 это удобный вариант передачи видео, поскольку размеры кадра, частота кадров и характеристики цветовой выборки могут быть прочитаны из заголовка. Файл можно заранее подготовить, а можно подать по стандартному вводу из программы, которая умеет выдавать Y4M.

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

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

Передача через стандартный ввод

x265 принимает - как имя входа для stdin. Это позволяет соединить декодер или кадровый сервер с энкодером без промежуточного гигантского файла. В таком конвейере первая программа отвечает за чтение контейнера, декодирование, фильтры и формирование Y4M, а x265 получает уже готовую последовательность кадров. Сам x265 при этом остаётся именно HEVC-энкодером и не начинает понимать исходный контейнер.

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

Сырой YUV: когда нужно описывать кадры вручную

В raw YUV нет контейнерного заголовка, поэтому ширина, высота, частота кадров, глубина и схема субдискретизации должны соответствовать реальным байтам файла. Параметр --input-res WxH задаёт геометрию, --fps — частоту, --input-depth — глубину, а --input-csp — цветовое пространство входных плоскостей.

Ошибка в любом из этих полей не просто меняет метаданные. Если указать неправильное разрешение, энкодер начнёт делить последовательность байтов на кадры не той длины. Визуально это может выглядеть как сдвиги, повторяющиеся части изображения, неверная хрома или полный мусор. Неверный CSP способен перемешать ожидания о размерах цветовых плоскостей. Поэтому параметры raw YUV должны браться из надёжно известного описания источника.

При работе с 10- или 12-битным входом важно различать глубину входных кадров и глубину кодируемого HEVC-потока. --input-depth описывает данные на входе, а --output-depth — внутреннюю глубину энкодера и результат. Эти значения могут быть связаны, но выполняют разные функции; нельзя использовать одно как универсальную замену другому.

Частота кадров и тайминг

Для Y4M частота может определяться автоматически из заголовка. Для raw YUV её задают через --fps, причём рациональная форма вроде 24000/1001 предпочтительна, когда исходный материал имеет дробную телевизионную частоту. Параметр влияет на временные сведения потока и расчёты битрейта, поэтому подставлять округлённое число без необходимости не стоит.

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

Выход: элементарный HEVC-поток

CLI x265 всегда записывает raw HEVC bitstream и не создаёт MP4, MKV или другой медиаконтейнер. Это ограничение определяет рабочий процесс: после кодирования поток обычно нужно мультиплексировать вместе со звуком и другими дорожками. Расширение выходного файла может быть .hevc, .h265 или иным привычным для сырого потока, но смена расширения на .mp4 не добавит контейнерную структуру.

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

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

Пресеты: управление скоростью и глубиной поиска

Параметр --preset переключает согласованные наборы инструментов кодирования. В документации перечислены значения ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow и placebo; по умолчанию используется medium. Разница между ними не сводится к одному числу качества: пресет меняет глубину и стоимость анализа, набор эвристик и другие параметры.

Медленный пресет не означает автоматического увеличения разрешения или добавления деталей, отсутствующих в исходнике. Он даёт энкодеру больше возможностей искать эффективное представление тех же кадров. В режиме CRF это обычно означает другой баланс размера и качества при той же целевой метрике rate control, а в режиме заданного битрейта — другое распределение доступных битов.

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

Настройки tune и их назначение

--tune корректирует выбранный пресет под определённый тип материала или критерий. В актуальной документации встречаются psnr, ssim, grain, zero-latency, fast-decode и animation. Tune не является готовым профилем доставки: он меняет инструменты анализа и психовизуальные решения, а требования к профилю HEVC, уровню и VBV задаются отдельно.

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

zero-latency сокращает буферизацию анализа и перестраивает структуру кодирования для сценариев, где важна задержка. В частности, tune убирает B-кадры, lookahead и ряд решений, которым нужны будущие кадры. За снижение задержки приходится платить меньшей свободой энкодера в выборе межкадрового предсказания и распределении битов.

fast-decode предназначен для облегчения декодирования и отключает часть инструментов, способных увеличить вычислительную стоимость воспроизведения. animation подстраивает несколько параметров под рисованную графику и типичные для неё плоские области и контуры. psnr и ssim смещают решения в сторону соответствующей объективной метрики; это не то же самое, что настройка на субъективное восприятие человеком.

CRF: кодирование с управлением качеством

CRF — основной режим quality-controlled variable bitrate в x265. Он включается параметром --crf, а значение по умолчанию в документации — 28. Чем больше число CRF, тем сильнее квантование, тем ниже обычно размер потока и хуже качество; уменьшение числа действует в обратную сторону. Но один и тот же CRF не обещает одинаковый битрейт для разных роликов: сложная сцена может получить заметно больше данных, чем статичная.

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

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

x265 --preset slow --crf 24 input.y4m -o output.hevc

Если результат требуется подстроить, сначала разумно менять один крупный параметр за раз. Например, сравнить соседние CRF при неизменном пресете на репрезентативном отрезке, а не одновременно крутить AQ, deblock, psy-rd, lookahead и структуру GOP. Так проще понять причину изменения результата и не построить конфигурацию из взаимно компенсирующих опций.

CRF и ограничения VBV

CRF можно сочетать с VBV, когда поток должен соблюдать ограничения по пиковой скорости. Для этого задаются --vbv-maxrate и --vbv-bufsize. В таком режиме x265 по-прежнему стремится следовать качественному поведению CRF, но должен укладываться в модель виртуального буфера. Если лимиты тесные, именно VBV может стать доминирующим ограничением на сложных сценах.

Нельзя использовать только название устройства или платформы как замену реальным числам VBV. Допустимые значения следует брать из спецификации целевого профиля доставки, а затем проверять совместно с profile, level, tier, разрешением и частотой кадров. Слишком маленький буфер может заставить rate control резко экономить биты на пиках сложности.

ABR: когда нужен заданный средний битрейт

Параметр --bitrate включает single-pass ABR и задаёт целевой средний битрейт в килобитах в секунду. Этот режим полезен, если размер или пропускная способность важнее равномерного качества CRF. Например, при заданном бюджете 5000 кбит/с команда может выглядеть так:

x265 --preset medium --bitrate 5000 input.y4m -o output.hevc

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

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

Строгий CBR и его границы

x265 содержит режим строгого CBR, связанный с VBV и ABR, но даже в таком сценарии важно понимать модель буфера и требования транспортной системы. Термин CBR в видеокодировании не следует трактовать как требование, чтобы каждое мгновение имело абсолютно одинаковое число битов. Кодек формирует кадры различного типа и сложности, а буфер сглаживает эти колебания.

Если поток предназначен для системы с жёсткими ограничениями, проверяют не только среднее число из итоговой строки, но и соответствие модели VBV, параметрам HRD и спецификации упаковки. Сам raw HEVC-файл x265 не заменяет транспортный мультиплексор и не гарантирует характеристики конечного канала только потому, что в командной строке указано слово bitrate.

VBV: ограничение пикового расхода битов

Video Buffering Verifier моделирует декодирующий буфер и помогает держать поток в пределах заданной пропускной способности. Два основных параметра — --vbv-maxrate для максимальной скорости поступления и --vbv-bufsize для размера буфера. Они работают совместно; при использовании CRF документация прямо требует задавать оба.

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

Пример с ABR и ограничением пика:

x265 --bitrate 5000 --vbv-maxrate 6000 --vbv-bufsize 12000 input.y4m -o output.hevc

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

Начальное заполнение и поведение буфера

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

При возникновении резких просадок качества на отдельных сценах в ограниченном потоке следует проверить, не упирается ли rate control в VBV. Полезно сопоставить настройки maxrate/bufsize с реальным целевым каналом и посмотреть подробный лог или CSV. Увеличивать психовизуальные параметры в такой ситуации вслепую — не решение: первопричиной может быть недостаточный битовый бюджет.

Многопроходное кодирование

Опция --pass включает многопроходный режим. На первом проходе x265 собирает статистику о последовательности и записывает её в файл; на финальном проходе эта информация используется для более осмысленного распределения заданного битрейта. Документация допускает значения pass 1–3 и отдельную модель для промежуточных проходов.

Имя файла статистики задаёт --stats; если его не указывать, используется стандартное имя x265_2pass.log. Все проходы одной задачи должны обращаться к согласованной статистике и одинаково описывать входную последовательность. Если на втором проходе поменять монтаж, число кадров, геометрию или существенные параметры анализа, накопленные данные могут перестать соответствовать материалу.

Пример двух проходов для целевого ABR:

x265 --preset slow --bitrate 5000 --pass 1 --stats movie.stats input.y4m -o first-pass.hevc
x265 --preset slow --bitrate 5000 --pass 2 --stats movie.stats input.y4m -o final.hevc

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

Быстрый первый проход

Опция --slow-firstpass управляет тем, можно ли упрощать анализ на первом проходе. По умолчанию x265 способен использовать ускоренные настройки первого прохода для повышения производительности. Если включён slow-firstpass, первый проход выполняется ближе к полному набору параметров. Выбор зависит от того, важнее ли время подготовки статистики или точность конкретной схемы двух проходов.

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

Профили HEVC и глубина 8, 10, 12 бит

Ключ --output-depth выбирает внутреннюю глубину и битовую глубину выходного HEVC: 8, 10 или 12. Сборка должна содержать или уметь привязать соответствующий вариант libx265. Если запрошенная глубина отличается от связанной библиотеки, CLI пытается подключить вариант libx265_main, libx265_main10 или libx265_main12 с совместимой версией API.

--profile ограничивает битстрим требованиями конкретного профиля. Для 8 бит документация перечисляет, в частности, Main и варианты Main 4:4:4; для 10 бит — Main 10, Main 4:2:2 10 и Main 4:4:4 10; для 12 бит — Main 12, Main 4:2:2 12 и Main 4:4:4 12. Также существуют intra- и still-picture варианты для соответствующих сценариев.

Если профиль задан явно, x265 проверяет, может ли выбранный набор параметров ему соответствовать. Это полезный механизм защиты от несовместимых сочетаний глубины, хромы и инструментов. Не следует использовать --allow-non-conformance как привычный способ починить ошибку профиля: этот ключ разрешает формирование несоответствующего потока и имеет смысл только при осознанной экспериментальной задаче.

Main, Main 10 и выбор для воспроизведения

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

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

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

x265 умеет работать с несколькими цветовыми пространствами, а выбранный профиль должен соответствовать выходной хроме. Потребительское HEVC чаще всего встречается как 4:2:0, тогда как 4:2:2 и 4:4:4 применяются в более специализированных рабочих процессах. Наличие поддержки на стороне энкодера не гарантирует, что конкретный аппаратный декодер воспроизведёт такой поток.

Для raw YUV входная схема задаётся --input-csp. Если кадры на диске фактически i422, а команда объявляет i420, проблема не сводится к профилю HEVC: энкодер неверно интерпретирует исходные плоскости. Поэтому сначала обеспечивают корректное чтение входа, затем выбирают требуемый выходной профиль и глубину.

Level и tier: не путать с пресетом

HEVC level описывает ограничения потока, связанные с разрешением, частотой, битрейтом, буферами и другими параметрами декодирования. Tier задаёт класс ограничений битрейта в рамках уровня. Это совершенно другая система, чем --preset slow или --preset fast: пресет влияет на сложность работы энкодера, а level/tier — на характеристики совместимого битстрима.

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

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

GOP и ключевые кадры

Структура GOP определяет, как часто в потоке появляются точки произвольного доступа и каким образом кадры ссылаются друг на друга. В x265 параметры --keyint и --min-keyint задают максимальный и минимальный интервал между ключевыми кадрами, а логика scenecut может вставить ключевой кадр в месте существенного изменения содержимого. Это влияет одновременно на эффективность сжатия, перемотку, сегментацию и задержку.

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

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

Open GOP и closed GOP

Open GOP допускает некоторые ссылки через границу группы и может повысить эффективность кодирования. Closed GOP делает границы более независимыми, что важно для отдельных сценариев нарезки и для функций x265, которым нужны закрытые группы. Например, параметры chunk start/end в документации работают только при closed GOP.

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

B-кадры, lookahead и адаптация структуры

B-кадры могут использовать ссылки на изображения с обеих сторон по времени и обычно дают эффективное сжатие, но усложняют кодирование и добавляют задержку. Параметр --bframes ограничивает максимальное число последовательных B-кадров, а --b-adapt определяет, насколько активно x265 выбирает их расположение по содержимому.

--rc-lookahead задаёт, сколько будущих кадров анализируется для решений rate control и структуры кадров. Большой lookahead даёт больше контекста, но увеличивает задержку и расход памяти. В tune zero-latency lookahead отключается именно потому, что ожидание будущих кадров противоречит задаче минимальной задержки.

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

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

Для интерактивной передачи разумнее начинать с --tune zero-latency, а не вручную отключать случайный набор функций. Tune убирает B-кадры, lookahead, scenecut и связанные механизмы, а также ограничивает кадровую многопоточность. После этого уже можно добавлять ограничения VBV и параметры канала.

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

Оценка движения

Межкадровое предсказание — один из центральных механизмов HEVC. x265 ищет области в ссылочных кадрах, похожие на кодируемый блок, и передаёт вектор движения вместе с остаточной разницей. Параметры метода motion estimation, диапазона поиска и субпиксельного уточнения определяют, сколько работы энкодер готов потратить на этот поиск.

Увеличение диапазона --merange не является универсальным способом улучшения качества. Если реальное движение находится внутри обычной области поиска, дальнейшее расширение только увеличит стоимость анализа. На материале с быстрыми перемещениями или нестандартным масштабом польза возможна, но её лучше проверять на конкретных сценах.

Субпиксельная оценка уточняет положение вектора между целыми пикселями. Более глубокий поиск способен уменьшить остаток, но требует дополнительных вычислений. Пресеты x265 согласуют эти параметры с уровнем RDO и другими эвристиками, поэтому ручная настройка одного subme вне контекста может дать меньше пользы, чем ожидается.

Reference frames и ограничения поиска

Количество ссылочных кадров определяет, сколько уже декодированных изображений может рассматриваться для предсказания. Больше ссылок повышает шанс найти хорошее соответствие, но увеличивает объём анализа и требования к декодирующему буферу. Параметры limit-refs позволяют сократить число реально исследуемых ссылок для отдельных блоков и получить компромисс между скоростью и полнотой поиска.

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

RDO и разбиение кадра на блоки

HEVC разбивает изображение на Coding Tree Units и рекурсивно выбирает размеры блоков. x265 оценивает множество вариантов предсказания и трансформации, пытаясь найти выгодный баланс между искажением и количеством битов. Параметр --rd задаёт глубину rate-distortion optimization: более высокие уровни включают более дорогие проверки.

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

Размер CTU, минимальный CU и глубина transform unit влияют на то, насколько гибко энкодер описывает области разного масштаба. Крупные однородные зоны выгодно кодировать большими блоками, мелкие детали и границы требуют более точного разбиения. Чем больше вариантов рассматривается, тем выше цена анализа.

Rect, AMP и merge

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

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

Психовизуальная оптимизация: psy-rd и psy-rdoq

Оптимизация только по математической ошибке не всегда совпадает с тем, что выглядит лучше. --psy-rd добавляет психовизуальное предпочтение в решения RDO, а --psy-rdoq воздействует на этап RDOQ. Они помогают удерживать визуально значимую текстуру, но могут ухудшать показатели PSNR или SSIM, потому что объективная ошибка распределяется иначе.

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

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

Adaptive Quantization и CU-tree

Adaptive Quantization распределяет квантование внутри кадра неодинаково. Идея состоит в том, что разные области изображения по-разному воспринимают потерю деталей: плоский тёмный участок и фактурная светлая зона не должны обязательно получать один и тот же QP. x265 предлагает несколько режимов AQ и параметр --aq-strength для силы воздействия.

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

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

Размер quantization group

--qg-size управляет пространственной гранулярностью некоторых решений AQ. Меньшая группа позволяет точнее менять QP внутри CTU, но увеличивает количество локальных решений и служебную сложность. Этот параметр имеет смысл трогать только после выбора режима AQ и понимания того, какие артефакты пытаются исправить.

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

Deblock, SAO и петлевые фильтры

HEVC применяет фильтры внутри контура декодирования, поэтому их результат становится частью ссылочных изображений. Deblocking уменьшает блочные границы, а Sample Adaptive Offset корректирует систематические ошибки реконструкции. Эти инструменты влияют и на внешний вид текущего кадра, и на качество последующего межкадрового предсказания.

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

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

Strong intra smoothing

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

Потоки CPU, WPP и NUMA

x265 рассчитан на многопроцессорную работу и использует thread pools. В логе отображается число потоков и такие функции, как wavefront parallel processing. WPP позволяет параллельно обрабатывать строки CTU с зависимостями между ними, повышая загрузку многопроцессорной системы без необходимости делить кадр на полностью независимые срезы.

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

--frame-threads задаёт число кадров, кодируемых параллельно. Кадровая параллельность повышает загрузку процессора, но увеличивает задержку и может ограничивать некоторые зависимости анализа. Именно поэтому zero-latency уменьшает эту составляющую. Максимальное число потоков не обязано давать максимальную скорость, если другие стадии или память становятся узким местом.

WPP и slices — разные механизмы

Wavefront parallel processing не следует путать с --slices. Срезы создают более независимые части изображения, которые можно декодировать раздельно, но такая независимость ограничивает эффективность предсказания через границу. Документация рекомендует использовать несколько slices для производительности только там, где frame parallelism и WPP не способны загрузить доступное оборудование.

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

Цветовые метаданные VUI

Сжатие пикселей и описание того, как их интерпретировать, — разные задачи. В x265 можно сигнализировать цветовые primaries, transfer characteristics и matrix coefficients, а также диапазон. Эти значения должны соответствовать реальному преобразованию, выполненному до энкодера. Простая запись bt2020 в метаданные не превращает BT.709-кадры в широкую цветовую гамму.

Для SDR HD часто применяются характеристики семейства BT.709, для UHD/HDR могут потребоваться BT.2020 primaries и соответствующая transfer-функция, но конкретные значения определяются мастерингом. Если декодер получает неверный matrix coefficient или range, визуально это может проявиться как смещение цветов, контраста или уровней, хотя сами кодированные коэффициенты были получены без ошибки.

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

Full range и limited range

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

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

x265 умеет передавать сведения mastering display по SMPTE ST 2086 через --master-display и уровни яркости контента через --max-cll. Параметр --hdr10 включает сигнализацию, связанную с HDR10, а --hdr10-opt меняет некоторые решения энкодера с учётом HDR. Значения должны поступать из достоверного мастер-файла или спецификации проекта.

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

Для HDR особенно важна 10-битная цепочка. Нужно убедиться, что декодер не преобразовал материал в 8 бит до x265, что --input-depth соответствует поступающим кадрам и что выбран Main 10 либо другой требуемый профиль. Одновременно сигнализируются правильные primaries, transfer и matrix.

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

Для динамических HDR10+ данных x265 поддерживает передачу вспомогательной информации из файла JSON через соответствующий параметр динамических HDR10-метаданных. Сам энкодер не должен придумывать покадровый тональный сценарий: он получает готовые метаданные и встраивает их в поток в предусмотренной форме.

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

Dolby Vision RPU

x265 имеет параметры для выбора поддерживаемого Dolby Vision profile и для передачи RPU-данных. Здесь особенно важно не смешивать кодирование базового HEVC-слоя с созданием Dolby Vision-метаданных. RPU должен быть получен из корректного источника и синхронизирован с кадрами; x265 отвечает за его включение в формируемый поток согласно доступным функциям.

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

Логирование и CSV

--log-level выбирает объём сообщений: error, warning, info, debug или full; уровень none оставляет лишь отдельные фатальные сообщения. По умолчанию используется info. --no-progress отключает периодическое обновление строки прогресса, что удобно в автоматизированных журналах, где возврат каретки мешает чтению.

--csv записывает статистику в файл CSV. В зависимости от уровня CSV-логирования можно получить строку на запуск или более подробные сведения по кадрам, включая порядок кодирования, тип кадра, POC, QP, число битов и признак scenecut. Такие данные полезнее догадок, когда нужно понять, что происходило на проблемном участке.

Лог консоли также удобно сохранять вместе с итоговым файлом и командой. Это позволяет позже восстановить применённый профиль, глубину, параметры GOP, AQ и rate control. Контейнерные теги иногда содержат строку writing library, но она не заменяет полный журнал с точной командой.

PSNR и SSIM

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

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

Сохранение и повторное использование анализа

x265 умеет сохранять результаты анализа и использовать их в другом проходе или связанном кодировании. Это отличается от обычного двухпроходного rate control: файл анализа содержит решения энкодера о блоках, режимах и движении, а параметры --analysis-save, --analysis-load и уровни повторного использования определяют, какой объём этих сведений можно переносить.

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

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

Multi-pass-opt-analysis и multi-pass-opt-distortion

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

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

Zones: локальное изменение rate control

Zones позволяют изменить поведение rate control на заданных диапазонах кадров. Для зоны можно задать множитель битрейта или значение QP в зависимости от выбранного синтаксиса. Это инструмент для осознанной локальной коррекции, когда заранее известен участок, которому требуется иной приоритет.

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

Зона не заменяет нормальную работу AQ и CRF. Если большая часть ролика требует ручной подстройки, это сигнал пересмотреть общий rate control. Zones лучше использовать для редких исключений, а не как способ покадрово управлять всем фильмом.

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

Параметр --lossless переводит x265 в режим, где реконструированные кадры должны совпадать с исходными пикселями. При этом обычный rate control по определению отключается, поскольку задача больше не состоит в выборе степени потерь. Энкодер продолжает использовать intra- и inter-предсказание, но остаток кодируется без потерь за счёт bypass трансформации и квантования в соответствующих участках.

Lossless HEVC не означает маленький файл. Размер зависит от предсказуемости материала, шума, разрешения и пресета. Медленные пресеты могут найти более эффективное представление без изменения пикселей, но требуют больше времени. Для шумного источника поток способен быть очень большим, потому что случайную текстуру сложно предсказывать.

Режим без потерь полезен как промежуточный мастер или для технической проверки, но совместимость с бытовыми декодерами следует тестировать отдельно. Устройство, которое заявляет воспроизведение HEVC Main/Main10, не обязано одинаково хорошо работать со всеми необычными сочетаниями профилей и lossless-инструментов.

Scaling lists и матрицы квантования

x265 поддерживает scaling lists — матрицы, меняющие относительную стоимость частотных коэффициентов. Их можно использовать для специализированной настройки квантования. Это уже не ползунок качества, а низкоуровневый инструмент, который имеет смысл при наличии проверенной матрицы и понятной цели.

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

Chunk encoding и разбиение длинной последовательности

Параметры --chunk-start и --chunk-end позволяют кодировать часть последовательности, сохраняя контекст вокруг границ. Кадры до chunk-start могут быть обработаны для подготовки состояния, но отброшены из битстрима; кадры после chunk-end могут участвовать в lookahead, не попадая в результат. Документация указывает, что эта функция требует closed GOP.

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

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

ABR ladder: несколько представлений одного видео

x265 содержит режим ABR ladder, в котором конфигурации нескольких энкодеров задаются в файле, а анализ может повторно использоваться между представлениями. Каждая строка описывает идентификатор кодирования, уровень reuse, ссылочное представление и набор CLI-параметров. Такой подход предназначен для построения набора разрешений или битрейтов для адаптивной доставки.

Главная экономия здесь достигается не тем, что один готовый HEVC-файл пережимается в остальные, а тем, что между связанными энкодерами можно повторно использовать часть анализа исходной последовательности. Каждое представление всё равно получает собственный битстрим и собственные ограничения rate control.

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

MCSTF для шумных источников

Motion-Compensated Spatio-Temporal Filtering, включаемый --mcstf, использует движение и соседние кадры для фильтрации шумоподобной составляющей до основных решений кодирования. Параметр --mcstf-ref-range управляет числом соседних ссылок для фильтра и принимает ограниченный диапазон значений, а selective MCSTF может применять обработку только там, где оценка шума показывает её необходимость.

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

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

Foveated encoding

Foveated encoding пространственно меняет качество относительно точки взгляда. Параметр --fovea-gaze задаёт координату, --fovea-delta определяет силу изменения качества к периферии, а --fovea-sigma влияет на форму области. Если delta равен нулю, механизм фактически отключён.

Для покадрово меняющейся точки взгляда предусмотрен --fovea-gaze-file. Такой файл должен соответствовать кадрам последовательности, поэтому после изменения монтажа или частоты его требуется синхронизировать заново. Функция предназначена для сценариев, где известна или моделируется область зрительного внимания; применять её к обычному фильму без данных взгляда только ради уменьшения размера было бы произвольным.

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

Screen Content Coding

Опция --scc включает инструменты Screen Content Coding, ориентированные на кадры с текстом, интерфейсной графикой, резкими краями и повторяющимися синтетическими структурами. Функция доступна только в сборках, скомпилированных с ENABLE_SCC_EXT. В документации предусмотрены два режима intrablock copy: ограниченный поиск и более полный, требующий больше времени.

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

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

Alpha channel

Поддержка alpha в x265 является условной возможностью сборки и включается при компиляции с ENABLE_ALPHA. CLI ожидает соответствующий формат YUVA420, а параметр --alpha активирует кодирование прозрачности. Обычный бинарник без этой функции не обязан принимать такой вход.

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

Также важно не путать YUVA-вход с обычным YUV 4:2:0: дополнительная плоскость меняет структуру кадров. Подставить альфа-канал одной опцией к файлу, в котором его физически нет, невозможно.

MV-HEVC и несколько представлений

Многовидовое HEVC доступно только в сборках, где включён ENABLE_MULTIVIEW. Конфигурационный файл описывает число видов, способ упаковки входов и пути к ним, а общие характеристики вроде глубины, CSP, разрешения и FPS задаются обычными параметрами CLI и должны соответствовать ожиданиям режима.

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

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

Опция --recon-y4m-exec позволяет передать реконструированные x265 кадры внешней программе, читающей Y4M из stdin. Это удобно для быстрой визуальной проверки того, что энкодер получает правильный вход и что базовые настройки rate control выглядят ожидаемо. Такой просмотр не заменяет тест окончательного контейнера.

У реконструированного preview нет нормального тайминга воспроизведения: скорость определяется темпом кодирования и задержками. Если slow-пресет кодирует несколько кадров в секунду, внешний проигрыватель не будет показывать материал с исходной скоростью. Функция предназначена именно для визуального контроля, а не для оценки плавности воспроизведения.

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

Для архивной задачи без жёсткого размера разумно начать с Y4M-входа, выбрать пресет по доступному времени и использовать CRF. Минимальная команда остаётся короткой: x265 --preset slow --crf 24 input.y4m -o archive.hevc. Затем на коротких фрагментах оценивают, подходит ли баланс качества и размера.

Если источник 10-битный и требуется сохранить 10-битный путь, добавляют --output-depth 10 и профиль Main 10. Если материал HDR, отдельно переносят достоверные colorimetry и HDR-метаданные. Если это SDR, не нужно добавлять HDR-флаги на всякий случай.

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

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

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

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

Финальный средний битрейт может не совпасть с целью до последнего бита из-за структуры кодека и ограничений, но двухпроходная модель позволяет использовать знания о всём ролике для распределения бюджета. Именно в этом её преимущество над single-pass ABR.

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

Если устройство или канал задаёт максимальный битрейт и буфер, к CRF или ABR добавляют --vbv-maxrate и --vbv-bufsize, затем выбирают совместимые profile/level/tier. Ключевые кадры согласуют с требованиями сегментации или перемотки. Такой профиль тестируют не только в программном декодере на ПК, но и на реальном целевом устройстве.

Нельзя заменять фактические лимиты названием 4K или HDR. Два 4K-устройства могут поддерживать разные уровни, частоты, форматы хромы и HDR-сигнализацию. Настройки x265 должны следовать точной спецификации, а не общему маркетинговому обозначению.

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

Для потоковой передачи с минимальной задержкой начинают с --tune zero-latency. Он убирает B-кадры и lookahead, отключает scenecut и CU-tree, а кадровую параллельность ограничивает так, чтобы энкодер не накапливал большую очередь. Далее задают rate control и VBV под сеть.

В таком режиме качество на том же битрейте может быть ниже, чем у офлайнового encode с глубоким анализом, потому что x265 не видит будущие кадры. Это нормальный компромисс, а не ошибка. Если задержка допускает дополнительный буфер, её можно постепенно обменивать на эффективность, но тогда профиль перестаёт быть истинным zero-latency.

Практический сценарий: 10-битный HDR10

Рабочая цепочка должна сохранить 10-битные кадры от декодера до x265. Затем выбираются --output-depth 10 и профиль Main 10, задаются корректные color primaries, transfer и matrix, а из мастер-метаданных переносятся mastering display и MaxCLL/MaxFALL. Если проект содержит HDR10+, динамические данные синхронизируются с кадрами.

Важнее всего не полный набор HDR-флагов, а их достоверность. Неправильный BT.2020 или ST 2086 способен сделать результат формально похожим на HDR-поток, но семантически неверным. Энкодер не анализирует художественный замысел и не может определить отсутствующие параметры мастеринга сам.

Ошибки запуска и коды возврата

CLI использует отдельные коды возврата: 0 означает успешное кодирование, 1 — невозможность разобрать командную строку, 2 — невозможность открыть энкодер, 3 — невозможность сформировать заголовки потока, 4 — аварийное завершение энкодера. Автоматизированный сценарий должен проверять код, а не только наличие файла на диске.

Код 1 чаще всего указывает на неизвестный ключ, отсутствующее значение или лишний позиционный аргумент. Сначала запускают x265 --help именно из того бинарника, который выполняет задачу, и сверяют написание опций. Команда из старой инструкции может содержать параметр, переименованный или недоступный в конкретной сборке.

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

Unknown option

Если x265 пишет, что опция неизвестна, есть три типичных причины: ошибка в имени, параметр из другой версии документации или функция, отключённая при сборке. Последнее особенно характерно для SCC, alpha и multiview. Нельзя считать, что любой бинарник x265 содержит все экспериментальные расширения только потому, что они описаны в master-документации.

Profile not supported и non-conformance

При ошибке профиля сначала проверяют выходную глубину, CSP, intra/still-picture режимы и инструменты, несовместимые с выбранным профилем. Если цель — обычный совместимый файл, исправляют конфликт. --allow-non-conformance не является безопасной кнопкой продолжить: он предназначен для случаев, когда пользователь сознательно допускает поток вне требований профиля.

Неверные цвета или уровни

Если результат выглядит выцветшим или слишком контрастным, нужно проверить всю цепочку: реальные значения пикселей, диапазон, matrix, primaries и transfer. x265 не знает, была ли до него выполнена конвертация цвета. Ошибка может находиться в декодере, фильтре, параметрах Y4M, VUI или проигрывателе.

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

Неправильная геометрия raw YUV

Полосы, горизонтальный сдвиг, повторение части кадра или хаотичная хрома часто указывают на неверные --input-res, --input-csp или --input-depth. Для диагностики полезно проиграть тот же raw-файл в программе, где все эти параметры задаются вручную. Если изображение уже там неверно, x265 не является источником проблемы.

Слишком низкая загрузка CPU

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

На большой системе проверяют WPP, thread pools и NUMA. Увеличение slices может поднять параллелизм, но способно снизить эффективность сжатия, поэтому это не первый универсальный шаг. Также не стоит сравнивать процент CPU между разными пресетами без учёта fps: более сложный анализ может сильнее нагружать одно ядро или ограничивать другие стадии.

Слишком большой файл в CRF

CRF не обещает фиксированный размер. Если шумный или детализированный материал внезапно дал большой поток, это может быть правильным следствием выбранного качества. Сначала сравнивают CRF, tune и источник; затем решают, действительно ли нужен лимит. Если размер является жёстким требованием, логичнее использовать ABR/2-pass либо сочетание CRF с обоснованным VBV.

Провалы качества при жёстком VBV

Когда сложная сцена упирается в maxrate и маленький буфер, энкодер вынужден повышать QP. Решение — не скрывать проблему экстремальными psy-настройками, а проверить, реалистичны ли ограничения. Если канал менять нельзя, снижение сложности потока может потребовать другого разрешения, частоты или общего профиля качества.

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

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

После мультиплексирования проверяют уже конечный контейнер: длительность, синхронизацию звука, временную шкалу, перемотку, старт с ключевых точек и работу на целевом устройстве. Если raw HEVC декодируется правильно, а контейнер нет, проблема может быть в muxing или таймстампах.

Для автоматизированного контроля удобно сохранять CSV, полный лог и точную команду рядом с результатом. Это позволяет не спорить о том, какие настройки вроде бы использовались, а увидеть фактический профиль, rate control и параметры структуры.

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

Программа	Лучше подходит для	Главное ограничение
x265	Гибкого программного HEVC-кодирования на CPU с тонким управлением качеством, GOP, HDR и rate control	CLI выдаёт только raw HEVC и может требовать значительного процессорного времени
Kvazaar	Открытого программного HEVC-кодирования и исследовательских или автоматизированных конвейеров	Набор прикладных настроек и интеграций отличается от экосистемы x265
SVT-HEVC	Высокопараллельного программного HEVC-кодирования на многоядерных процессорах	Иная модель пресетов и параметров, готовые команды x265 напрямую не переносятся
NVEncC	Быстрого аппаратного HEVC-кодирования на совместимых видеокартах NVIDIA	Требует поддерживаемого NVENC и зависит от возможностей поколения GPU
QSVEncC	Быстрого аппаратного HEVC-кодирования через Intel Quick Sync Video	Требует совместимой графики Intel и доступных аппаратных функций

Если приоритет — максимальная управляемость программного HEVC-кодирования и возможность детально настраивать анализ, x265 остаётся прямым выбором. Kvazaar и SVT-HEVC интересны как альтернативные CPU-энкодеры с собственной архитектурой. NVEncC и QSVEncC решают тот же конечный класс задачи — HEVC-кодирование — но переносят основную работу на специализированные аппаратные блоки и поэтому выбираются прежде всего ради скорости и энергоэффективности.

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

Когда x265 подходит лучше всего

x265 уместен, когда нужен HEVC-поток с контролируемыми параметрами и есть возможность подготовить YUV/Y4M-вход. Это архивное перекодирование, пакетные конвейеры, подготовка потока под заданный VBV, HDR10/Main10, многоступенчатая обработка с кадровым сервером и разработческие сценарии, где важно воспроизводить команду буквально.

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

Когда лучше выбрать другой инструмент

Если задача формулируется как открыть MP4, подрезать, добавить субтитры, перекодировать звук и сохранить MKV, одного x265 недостаточно. Нужен конвертер или набор инструментов, который декодирует контейнер, выполняет фильтры и затем использует HEVC-энкодер. x265 может быть ядром видеокодирования внутри такого процесса, но сам не предоставляет интерфейс для всех стадий.

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

Если нужен AV1, VVC или H.264/AVC, требуется энкодер соответствующего стандарта. x265 не является универсальным x26x, который меняет выходной кодек ключом. Он формирует именно H.265/HEVC.

Краткая схема настройки без случайных флагов

1. Подготовить корректный Y4M или точно описанный raw YUV.
2. Выбрать глубину и профиль под реальный источник и целевой декодер.
3. Выбрать пресет по доступному времени кодирования.
4. Определить цель rate control: CRF для качества, ABR/2-pass для битового бюджета.
5. Добавить VBV только при наличии требований к пиковому потоку.
6. Настроить GOP и keyint под перемотку, сегментацию и задержку.
7. Выбрать tune, если материал или сценарий действительно ему соответствует.
8. Передать достоверные VUI/HDR-метаданные, не используя их как фильтр цвета.
9. Изменять низкоуровневые AQ, psy, motion и RDO-параметры по одному и проверять на типичных сценах.
10. Сохранить команду, лог, код возврата и при необходимости CSV.
11. Проверить raw HEVC независимым декодером, затем упаковать его в требуемый контейнер.
12. Проверить конечный файл на целевом устройстве, а не только на рабочем компьютере.

Итог

x265 даёт подробный контроль именно над HEVC-кодированием: от простого --preset + --crf до многопроходного ABR, VBV, профилей 8/10/12 бит, психовизуальной оптимизации, структуры GOP, HDR-метаданных, анализа reuse и специализированных режимов. Его сила раскрывается там, где входные кадры подготовлены корректно, а требования к результату сформулированы точнее, чем сделать файл поменьше.

Рабочий процесс надёжнее всего строить от крупных решений к мелким: сначала формат входа, глубина, профиль, пресет и rate control; затем GOP, VBV и метаданные; только после этого — тонкая настройка анализа. Такой порядок позволяет понимать причину каждого изменения и сохраняет команду воспроизводимой, что особенно важно для длительного кодирования и пакетных задач.

Constant QP: прямое управление квантователем

Параметр --qp включает режим Constant QP. Указанное значение назначается P-срезам, а QP для I- и B-срезов обычно вычисляется относительно него через коэффициенты ipFactor и pbFactor. Допустимый диапазон базового QP в документации — от 0 до 51. Этот режим нужен, когда требуется исследовать поведение энкодера при фиксированной базе квантования, а не управлять средним битрейтом или качественным фактором CRF.

QP 0 важно не путать с --lossless. Документация прямо отмечает, что нулевой QP отключает квантование, но не является полным режимом без потерь. Для гарантированного lossless используется отдельная опция, которая меняет обработку CU и отключает обычный rate control.

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

Ограничения QP в других режимах

--qpmin и --qpmax ставят жёсткие границы для rate control, а --qpstep ограничивает величину одиночного изменения QP. Эти параметры способны сделать поведение более предсказуемым, но чрезмерно тесные рамки мешают энкодеру реагировать на резкие изменения сложности. Если поток не укладывается в VBV, а qpmax запрещает достаточное повышение QP, конфигурация может стать внутренне противоречивой.

--qcomp управляет сжатием кривой квантователя на основе сложности residual, измеренной lookahead. Повышение значения делает распределение QP между простыми и сложными кадрами более равномерным; при значении 1.0 поведение приближается к CQP. Это тонкая настройка rate control, которую лучше менять только при понимании, какое распределение качества требуется.

Короткие тесты через seek и frames

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

x265 --seek 12000 --frames 500 --preset slow --crf 24 input.y4m -o sample.hevc

Номер кадра удобен для воспроизводимости, но при переменной кадровой частоте исходного контейнера временная позиция должна определяться ещё до передачи в x265. Сам Y4M-поток является последовательностью кадров, и seek считает именно их. Если декодирующая программа по-разному формирует вход между запусками, одинаковый номер может уже не соответствовать той же сцене.

Тестовый фрагмент должен быть достаточно длинным, чтобы показать типичное поведение GOP и rate control. Один I-кадр или пара секунд не характеризуют фильм. Для проверки VBV особенно полезны сложные переходы и сцены с быстрым движением, где буфер испытывает максимальную нагрузку.

Заголовки VPS, SPS, PPS и random access

HEVC-поток содержит наборы параметров VPS, SPS и PPS, которые сообщают декодеру основные характеристики последовательности. По умолчанию заголовки не обязательно повторяются перед каждым ключевым кадром. Опция --repeat-headers заставляет x265 помещать VPS/SPS/PPS вместе с ключевыми кадрами и предназначена для случаев, когда нет контейнера, который хранит заголовки отдельно, а ключевые кадры должны быть самостоятельными точками доступа.

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

AUD, EOB и EOS

--aud добавляет Access Unit Delimiter NAL к единицам доступа. --eob и --eos управляют специальными NAL в конце битстрима или последовательности. Эти флаги нужны при конкретных требованиях парсера, транспортной схемы или тестовой среды; обычное воспроизведение не требует включать все маркеры одновременно.

Если поток должен проходить через внешнее устройство, которое ожидает определённые NAL, его спецификацию следует читать буквально. Попытка исправлять несовместимость случайным набором AUD/EOS/repeat-headers может скрыть настоящую проблему в profile, level или упаковке.

Annex B и роль CLI

В API x265 существует выбор между Annex B с start codes и форматом с длинами NAL. Документация отмечает, что CLI выбирает правильный вариант исходя из выходного формата, а сам параметр --annexb относится к API. Для пользователя standalone CLI это ещё один пример границы между библиотекой x265 и командной оболочкой: не все поля x265_param предназначены для прямого переключения в терминале.

Когда x265 используется внутри мультиплексора через библиотеку, контейнер может требовать length-prefixed NAL. Когда CLI пишет сырой поток, типичным представлением является Annex B. Поэтому команды, предназначенные для libx265 внутри другой программы, нельзя автоматически переносить в standalone CLI без проверки документации.

Temporal layers

x265 поддерживает временные слои, при которых кадры организуются по иерархии temporal ID. Для некоторых конфигураций число B-кадров формирует фиксированный mini-GOP: документация приводит, например, структуры для трёх, четырёх и пяти temporal layers. Это специализированный инструмент для масштабируемых или ограниченных схем декодирования.

Временные слои не равнозначны обычному B-pyramid. Они задают явную иерархию доступности кадров, которую должен понимать downstream. Если конечная система не использует такую функцию, усложнять структуру потока нет причины. Кроме того, lookahead всё ещё способен влиять на размер mini-GOP в разрешённых случаях.

Scenecut-aware QP во втором проходе

Для pass 2 x265 предлагает --scenecut-aware-qp, который меняет QP inter-кадров в окне до и/или после смены сцены. Режимы позволяют применять forward masking, backward masking или оба направления. Цель — уменьшить расход битов там, где свойства зрительного восприятия вокруг резкой смены позволяют сделать это с меньшим визуальным ущербом.

--masking-strength задаёт длительность окон и величину прибавки QP для ссылочных и нессылочных кадров. Это не настройка для начинающего профиля, а точечный инструмент двухпроходного rate control. Ошибка в знаках, окнах или чрезмерное усиление способна сделать переходы заметно грубее.

Поскольку функция работает во втором проходе, её следует рассматривать вместе со статистикой первого. Если задача не использует multi-pass, этот механизм не является способом улучшить scenecut в обычном CRF.

Adaptive Frame Duplication

В CLI есть механизм Adaptive Frame Duplication и порог --dup-threshold, задающий сходство кадров в диапазоне, определённом документацией. Функция предназначена для выявления практически одинаковых кадров и требует отдельного включения соответствующей логики. Она относится к специальным сценариям, где повторяющиеся изображения можно представить эффективнее.

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

CU-level lossless

Помимо глобального --lossless, существует --cu-lossless. При достаточно высоком RD x265 может проверить lossless-вариант для конкретного Coding Unit как одну из альтернатив rate-distortion. Это не делает весь поток без потерь: лишь отдельный блок может быть выбран без трансформации и квантования, если такой вариант оказывается выгодным в рамках RDO.

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

Поведение при fade-in и fade-out

Плавные затемнения и появления сложны для scenecut-логики, потому что множество кадров постепенно меняют яркость, сохраняя структуру сцены. x265 имеет параметр --fades, позволяющий обнаруживать и специальным образом обрабатывать fade-in участки. Функция по умолчанию отключена.

Если проект содержит множество длинных fades и на них видны нестабильные решения GOP или rate control, можно исследовать эту опцию на коротком отрезке. Но включать её для любого материала в надежде на общее повышение качества не требуется.

Экстренное поведение VBV

При включённом VBV и экстремальном дефиците битов x265 может применять emergency denoising на уровне кадра, когда QP выходит за обычный предел. Документация предупреждает, что визуальный эффект будет похож на размытие, но это позволяет резко снизить расход битов и вернуть буфер в управляемое состояние для последующих кадров.

Если такой режим срабатывает заметно, проблему нужно рассматривать как признак слишком жёсткого ограничения для выбранного материала, а не как обычный фильтр. Увеличение доступного maxrate/bufsize, изменение разрешения или более реалистичный целевой профиль обычно фундаментальнее, чем попытка скрыть последствия.

Как переносить настройки между оболочками и чистым x265

Многие конвертеры показывают в интерфейсе пресеты x265, CRF и дополнительные параметры, но при этом сами декодируют исходник, создают YUV-кадры и мультиплексируют контейнер. Если нужно повторить такой encode в standalone CLI, сначала надо отделить параметры собственно x265 от настроек фильтров, контейнера и программы-обёртки.

Например, строка libx265 в FFmpeg означает использование библиотеки x265 через API. Параметры передаются не обязательно тем же синтаксисом, что в standalone CLI. Часть полей задаётся общими опциями FFmpeg, часть — через список x265-params. Поэтому команду нельзя копировать посимвольно и ожидать, что executable x265 поймёт её.

Обратная ситуация аналогична: настройка, доступная в CLI x265, может отсутствовать в конкретной GUI-обёртке или появляться под другим названием. Надёжная проверка — посмотреть фактическую команду/лог, если оболочка их показывает, и сверить с документацией соответствующей версии библиотеки.

Как сравнивать два encode корректно

Чтобы понять влияние параметра, оба encode должны получать одинаковые кадры. Нельзя сравнивать один вариант после resize и denoise с другим, где фильтры отличались, и приписывать всю разницу x265. Также фиксируют глубину, CSP, FPS, пресет, tune и rate control, меняя только исследуемую настройку.

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

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

Минимальный набор данных для воспроизводимого проекта

Что сохранить	Зачем
Точную команду x265	Восстановить параметры кодирования без догадок
Версию и build info	Понимать доступные функции, глубину и особенности сборки
Описание входа	Проверить разрешение, FPS, CSP и bit depth
Консольный лог	Увидеть фактически применённый профиль, rate control и инструменты
CSV при сложной диагностике	Разобрать покадровые QP, биты, типы кадров и scenecut
Файлы stats/analysis	Повторить многопроходную или reuse-схему
HDR/RPU-метаданные	Сохранить точную служебную информацию мастера

Такой набор позволяет повторить проект даже после переноса на другой компьютер. Он также помогает редактору или инженеру быстро отделить проблему исходных кадров от проблемы конкретной сборки x265. Сохранять только итоговый HEVC и вспоминать настройки по MediaInfo значительно менее надёжно.

Финальная проверка перед длительным кодированием

Перед многочасовым запуском стоит выполнить --version, убедиться в нужной bit depth сборки, проверить короткий Y4M-фрагмент, прочитать начало лога и декодировать полученный HEVC. Для raw YUV отдельно подтверждаются resolution, fps, csp и depth. Для HDR проверяются VUI, mastering display и динамические данные, если они используются.

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