x264 кодирует видеопотоки в H.264/MPEG-4 AVC и позволяет точно управлять качеством, битрейтом, профилем, GOP, B-кадрами, VBV, цветовой метаинформацией и скоростью кодирования через параметры командной строки, что удобно для подготовки файлов, потоков и автоматизированных видеоконвейеров.
У x264 нет графического окна с панелями и меню: работа строится вокруг исполняемого файла, строки параметров и входного видеопотока. Это дает прямой доступ к режимам CRF, ABR и многопроходному кодированию, к пресетам скорости, настройкам анализа движения, структуре GOP, профилям и уровням H.264, ограничениям VBV, VUI-метаданным и параметрам низкой задержки. За счет такой схемы одна и та же конфигурация легко повторяется в пакетных заданиях, скриптах и конвейерах с AviSynth, Y4M или сырым YUV.
Главное ограничение x264 следует из его назначения: он кодирует именно видео в AVC/H.264 и не заменяет полноценный монтажный или медиаконвертирующий пакет. Аудиодорожки, субтитры, сложный монтаж и финальную упаковку нескольких потоков обычно берет на себя соседний инструмент, тогда как x264 отвечает за формирование видеопотока, его качество, совместимость и поведение декодера.
Скачать x264
- Конвертация видео
- Сжатие файлов
- Просто для новичков
- Нет графического интерфейса
- Нет встроенного аудиокодера
- Только H.264/AVC
Что именно делает x264
x264 — программный кодировщик H.264/MPEG-4 AVC. Он принимает последовательность видеокадров, анализирует пространственную и временную избыточность, выбирает типы кадров и блоков, оценивает движение, распределяет биты и формирует AVC-поток с заданными ограничениями. Практически это означает, что пользователь определяет не только насколько сильно сжать материал, но и характер кодирования: постоянное субъективное качество, целевой средний битрейт, ограничение мгновенного битрейта, глубину анализа, набор допустимых инструментов H.264 и параметры совместимости с проигрывателями или вещательным трактом.
Внутри x264 объединены две роли: библиотека libx264 для встраивания в другие программы и консольный x264 CLI. В этой статье речь идет прежде всего о самом CLI, потому что именно он определяет синтаксис вроде --crf, --preset, --tune, --profile, --vbv-maxrate и остальных параметров. Когда другая программа использует libx264, названия настроек часто похожи, но конкретный интерфейс и способ передачи параметров уже принадлежат этой программе, а не x264.
Кодировщик не является универсальным декодером всего на свете. Возможности чтения контейнеров зависят от того, как собран конкретный бинарник: официальный справочный вывод допускает raw, YUV4MPEG, AviSynth, а при наличии соответствующей поддержки — libavformat или FFMS. Поэтому одна сборка может открыть MKV или MP4 напрямую, а другая потребует Y4M, AviSynth либо сырой поток. Это важно при переносе готовой командной строки между компьютерами: одинаковый x264-синтаксис еще не гарантирует одинаковый набор входных модулей.
Какие задачи хорошо ложатся на x264
- подготовка H.264-видеопотока для MP4, MKV, транспортных или вещательных цепочек;
- архивное и пользовательское кодирование с постоянным качеством CRF;
- доставка с заранее известным средним битрейтом через двухпроходный режим;
- потоки с ограничениями VBV, когда важны пиковый битрейт и размер буфера декодера;
- низколатентное кодирование с управлением B-кадрами, lookahead и sliced threads;
- встраивание H.264 в автоматические скрипты и серверные задачи без ручного интерфейса;
- контролируемое формирование профилей High, High 10, High 4:2:2 и High 4:4:4, если это поддерживает конкретная сборка и приемная сторона.
Синтаксис команды и первый запуск
Базовая форма команды предельно короткая: сначала вызывается x264, затем идут опции, после -o или --output указывается выходной файл и в конце — вход. На практике надежнее начинать именно с этой схемы и добавлять настройки постепенно. Если сразу вставить десятки параметров, ошибка в одном ключе, неподдерживаемый демультиплексор или конфликт профиля с выбранной цветностью могут маскировать первопричину.
Для изучения доступных ключей предусмотрены три уровня справки. --help показывает базовый набор, --longhelp — расширенный, а --fullhelp — полный перечень с редко используемыми параметрами. Это особенно полезно, если бинарник получен не из той же сборочной среды, что использовалась при подготовке инструкции: вывод справки одновременно показывает возможности входа, контейнеров и глубины цвета конкретного исполняемого файла.
x264 --help
x264 --longhelp
x264 --fullhelp
На снимке интерфейса x264 фактически является окно терминала: видны синтаксис, поддерживаемые входы и выходы, примеры CRF, двухпроходного режима и список пресетов. Это нормальная форма работы программы; отдельного окна настроек у CLI нет.
Минимальная команда постоянного качества
x264 --crf 20 --preset medium -o output.264 input.y4mВ этой строке --crf 20 задает режим постоянного визуального качества, --preset medium определяет компромисс между скоростью и эффективностью сжатия, а расширение .264 означает сырой AVC-поток. Значение CRF нельзя трактовать как процент качества: шкала нелинейна, и одна и та же цифра дает разный битрейт на простом мультфильме, шумной пленке и динамичном игровом видео.
Если конечный контейнер должен содержать звук, главы или субтитры, типичный рабочий процесс разделяет обязанности. x264 формирует видеопоток, после чего другой инструмент помещает его вместе с остальными дорожками в нужный контейнер. Некоторые сборки x264 умеют писать MKV, FLV или MP4, однако наличие конкретного muxer зависит от сборки, поэтому переносимая схема часто опирается на сырой AVC или на внешний мультиплексор.
Входные форматы: raw, Y4M, AviSynth, lavf и ffms
Самый предсказуемый вход для x264 — YUV4MPEG2, обычно с расширением .y4m. Заголовок Y4M несет разрешение, кадровую частоту, цветность и другие базовые сведения, поэтому не приходится вручную объяснять кодировщику геометрию каждого кадра. Для обмена между декодером/фильтром и x264 Y4M особенно удобен: поток можно передавать через стандартный ввод, сохраняя информацию о формате.
Сырой YUV лишен такого заголовка. Для него нужно явно указывать --input-res, формат цветности через --input-csp, а при необходимости глубину через --input-depth и частоту кадров через --fps. Если ошибиться хотя бы в одном из этих параметров, байты будут интерпретированы в неправильной геометрии или последовательности плоскостей, и результат окажется визуально поврежденным либо программа вообще не сможет корректно определить кадры.
AviSynth-вход удобен в Windows-сценариях, где декодирование, деинтерлейс, шумоподавление, ресайз и другие операции делаются в .avs-скрипте. Но поддержка AviSynth должна быть включена при сборке x264 и совпадать по архитектуре с используемым окружением. Если 64-битный x264 не видит 32-битный AviSynth или его плагины, внешне это часто выглядит как мгновенное закрытие консоли или ошибка открытия входа.
Модули lavf и ffms расширяют набор контейнеров и кодеков, которые можно открыть напрямую. Здесь важно не путать возможность прочитать файл с назначением самого x264: декодирование обеспечивает дополнительный входной модуль, а x264 по-прежнему выполняет H.264-кодирование. Для воспроизводимых производственных цепочек полезно фиксировать, какой именно demuxer задействован, особенно если разные системы собраны с разным набором библиотек.
| Параметр | Назначение | Практический смысл |
|---|---|---|
--demuxer auto|raw|y4m|avs|lavf|ffms | Выбор способа чтения входа | Помогает принудительно обойти неверное автоопределение или задать нужный модуль. |
--input-fmt | Формат входного файла для lavf | Нужен редко, когда контейнер нельзя надежно определить автоматически. |
--input-res W×H | Размер сырого кадра | Обязателен для raw, если геометрия не приходит из внешнего описания. |
--input-csp | Цветовое представление входа | Определяет порядок и тип плоскостей, например i420, i422, i444, rgb. |
--input-depth | Глубина raw-входа | Нужна для корректной интерпретации 8/10/16-битных промежуточных потоков. |
--fps | Частота кадров | Можно задавать десятичным числом или точной рациональной дробью вроде 24000/1001. |
--seek | Первый кодируемый кадр | Удобен для технического фрагмента или повторного кодирования участка. |
--frames | Максимальное число кадров | Полезен для коротких проб, проверки параметров и ограниченного тестового фрагмента. |
Режим CRF: качество как главная цель
--crf включает quality-based VBR: кодировщик не пытается удержать заранее заданный размер файла, а меняет битрейт в зависимости от сложности сцен, стремясь выдерживать выбранный уровень качества. Это типичный режим для файлового кодирования, когда важнее стабильное субъективное восприятие, чем точное попадание в мегабайты. Сложная сцена получает больше данных, статичная — меньше, поэтому итоговый размер заранее неизвестен.
Шкала CRF у x264 ориентирована так, что меньшее значение означает меньшее квантование и более высокое качество. Нулевое значение соответствует без потерь, а значение по умолчанию в справке — 23. Однако универсального правильного CRF нет. На результат влияют исходный шум, разрешение, частота кадров, пресет, tune, цветность, глубина и даже характер движения. Поэтому корректная практика — выбрать несколько коротких репрезентативных отрезков и сравнить соседние значения, а не переносить одну цифру на все источники.
Параметр --crf-max применяют вместе с VBV, чтобы ограничить максимальный rate factor. Это тонкая настройка: слишком жесткий предел может вступить в конфликт с буферной моделью и привести к недопустимым переполнениям или недогрузкам. В обычном файловом CRF без требований к каналу связи --crf-max чаще не нужен.
# Универсальная отправная точка для 4:2:0 материала
x264 --crf 20 --preset slow --profile high -o video.264 input.y4m
# Без потерь
x264 --qp 0 -o lossless.264 input.y4mCRF и preset нельзя оценивать независимо
При одном и том же CRF более медленный preset обычно тратит больше вычислений на поиск более выгодного представления кадра. Он не обязан давать заметно красивее каждый кадр при неизменном CRF, зато способен достигать сопоставимого качества при ином распределении битов и, как правило, более высокой компрессионной эффективности. Поэтому переход с medium на slow следует воспринимать как изменение алгоритмической тщательности, а не как прямое увеличение качества на фиксированную величину.
Preset placebo существует главным образом как крайняя точка поиска: он включает очень дорогие алгоритмы вроде tesa, большого числа ссылочных кадров и полного RD. В реальных задачах прирост эффективности относительно veryslow может быть непропорционально мал по сравнению с затратами времени. Для практической настройки разумнее выбрать самый медленный preset, который укладывается в допустимое время кодирования, а затем подбирать CRF.
ABR и двухпроходное кодирование
--bitrate переводит rate control в режим целевого среднего битрейта. В один проход x264 распределяет биты по мере анализа текущего и некоторого числа будущих кадров, стараясь в среднем приблизиться к заданной величине. Этот вариант нужен, когда пропускная способность или размер файла важнее, чем свобода кодировщика расходовать битрейт по сложности материала.
Двухпроходный режим дает rate control больше информации. На первом проходе x264 собирает статистику о сложности кадров и структуре материала, затем второй проход использует ее для более осмысленного распределения заданного бюджета битов. Это не двойное улучшение качества само по себе; преимущество в том, что при фиксированном среднем битрейте кодировщик заранее знает, где будущие сцены потребуют большего бюджета.
--pass 1 создает файл статистики, --pass 2 читает его и не перезаписывает, а --stats позволяет выбрать имя. Первый проход специально ускоряется набором упрощений. Если требуется отключить эти ускорения, используется --slow-firstpass, но делать это без конкретной причины обычно нет смысла: первый проход нужен прежде всего для построения модели сложности.
# Первый проход
x264 --pass 1 --bitrate 4500 --preset slow --stats movie.stats -o NUL input.y4m
# Второй проход
x264 --pass 2 --bitrate 4500 --preset slow --stats movie.stats -o movie.264 input.y4m
В нижней части справки x264 видны параметры frame type, rate control, input/output и встроенных фильтров. Такой экран полезен тем, что подтверждает синтаксис именно исполняемого файла, который будет запускаться в конкретной системе.
Когда два прохода оправданы
- есть жесткий общий бюджет на видео, например известный средний битрейт для носителя или канала;
- нужно сравнивать разные настройки при одинаковом битрейте;
- требуется более разумное распределение битов между простыми и сложными сценами при фиксированном среднем значении;
- время подготовки важнее, чем скорость одного прохода.
Если размер заранее не задан, CRF обычно проще: не приходится оценивать битрейт, а кодировщик сам тратит больше данных там, где они действительно нужны. Двухпроходный режим выигрывает не потому, что он качественнее вообще, а потому, что лучше решает задачу распределения фиксированного бюджета.
VBV: ограничение пикового битрейта и буфера
VBV моделирует ограничения приемной стороны. Пара --vbv-maxrate и --vbv-bufsize сообщает x264, какой локальный битрейт допустим и какой объем буфера доступен декодеру. Это принципиально отличается от простого среднего --bitrate: даже файл с умеренным средним потоком может иметь короткие пики, которые перегрузят слабый декодер, канал передачи или формальные требования профиля доставки.
--vbv-maxrate задается в кбит/с, --vbv-bufsize — в килобитах. --vbv-init определяет начальное заполнение буфера. Правильные значения берут из спецификации целевого устройства, сервиса или вещательного профиля, а не из типового рецепта. Если поставить слишком маленький буфер и низкий maxrate для сложного изображения, x264 будет вынужден резко повышать квантование в тяжелых сценах, что проявится потерей деталей и блоковыми артефактами.
Для сигнализации HRD применяется --nal-hrd. Режим cbr требует VBV и в сыром виде может дополняться filler-данными, чтобы сформировать жесткий CBR. При этом справка x264 отдельно указывает, что nal-hrd cbr не допускается для MP4-выхода самого x264. В файловых сценариях часто достаточно VBR с VBV, а не искусственного заполнения потока.
# Пример ограничения канала: средний 4000, пик 5000, буфер 10000 кбит
x264 --bitrate 4000 --vbv-maxrate 5000 --vbv-bufsize 10000 -o stream.264 input.y4mPresets: скорость против эффективности сжатия
--preset — один из самых важных инструментов x264. Он не выбирает разрешение, профиль доставки или качество видео напрямую, а меняет большой набор алгоритмических параметров, отвечающих за глубину поиска. Preset medium является базовым. В сторону ultrafast уменьшаются число ссылок, lookahead, сложность motion estimation, trellis, subme и другие механизмы; в сторону slow, slower, veryslow и placebo анализ становится тяжелее.
Главное практическое правило: preset меняет время и компрессионную эффективность, а CRF или bitrate задают цель rate control. Поэтому не стоит компенсировать медленный preset произвольным изменением десятков внутренних ключей, если нет конкретного измеримого требования. Система пресетов нужна именно для того, чтобы связанный набор настроек оставался внутренне согласованным.
| Preset | Что меняется по сути | Когда выбирать |
|---|---|---|
| ultrafast | Минимум анализа: без B-кадров, CABAC, deblock, mbtree; быстрый поиск движения. | Захват или сценарий, где скорость критичнее размера и эффективности. |
| superfast | Часть инструментов возвращается, но lookahead и анализ остаются очень ограниченными. | Очень быстрые задачи с небольшим запасом CPU. |
| veryfast | Более практичный быстрый баланс; ref=1, небольшой lookahead, упрощенный subme. | Поточные и массовые задания, где medium слишком тяжел. |
| faster / fast | Постепенно увеличивают ref, lookahead и subme. | Промежуточный компромисс между veryfast и medium. |
| medium | Набор настроек по умолчанию. | Хорошая контрольная точка для нового материала. |
| slow | Увеличивает lookahead и refs, включает direct auto и более дорогой анализ. | Файловое кодирование, когда есть запас времени. |
| slower | b-adapt 2, umh, все partitions, больше refs и subme. | Архивные/дистрибуционные задачи с приоритетом эффективности. |
| veryslow | Еще больше B-кадров, refs и motion search. | Когда время кодирования вторично. |
| placebo | Предельные tesa/subme/ref и отключение части ранних отсечений. | Исследовательские сравнения; редко рационален для повседневной работы. |
Tune: адаптация к типу материала и режиму работы
--tune накладывает дополнительный набор настроек поверх preset, а явно указанные пользователем параметры затем имеют приоритет. Это важно: tune не является жанровым фильтром и не меняет исходную картинку как эффект. Он перестраивает rate control, психовизуальные коэффициенты, deblocking, B-кадры и другие инструменты под характер источника или техническую задачу.
Из психовизуальных tunings одновременно выбирается только один. Отдельные технические tunings, например fastdecode или zerolatency, могут комбинироваться с психовизуальным через запятую, если сочетание имеет смысл. Нельзя считать tune обязательным: для большинства обычных кадров --preset ... --crf ... без tune является вполне нормальной исходной конфигурацией.
| Tune | Что делает | Типичный смысл |
|---|---|---|
| film | Слегка меняет deblock и psy-trellis. | Натуральное изображение с зерном и текстурой. |
| animation | Увеличивает B-кадры и refs при подходящих исходных значениях, меняет psy/deblock/AQ. | Рисованная и компьютерная анимация с ровными областями и четкими контурами. |
| grain | Снижает склонность съедать зерно, меняет qcomp, AQ и deadzone. | Сохранение пленочного зерна и высокочастотного шума, ценой битрейта. |
| stillimage | Усиливает психовизуальные настройки для почти статичных кадров. | Слайд-шоу, длительные неподвижные планы. |
| psnr | Отключает психовизуальные механизмы и AQ. | Тесты, оптимизированные под численный PSNR, а не субъективное восприятие. |
| ssim | Отключает psy и выбирает AQ mode 2. | Эксперименты, ориентированные на SSIM. |
| fastdecode | Отключает CABAC, deblock и weighted prediction. | Уменьшение нагрузки на декодирование ценой эффективности. |
| zerolatency | Убирает B-кадры и lookahead, включает sliced threads и force-cfr. | Интерактивные потоки, где задержка важнее эффективности. |
Profile и Level: совместимость с декодером
Профиль H.264 ограничивает набор инструментов, которые имеет право использовать поток. --profile не просто записывает метку в заголовок: x264 принудительно отключает несовместимые функции. Например, baseline не допускает B-кадры и CABAC, main исключает 8x8 transform, а high сохраняет более широкий набор инструментов 8-битного 4:2:0 AVC. Профили high10, high422 и high444 расширяют допустимую глубину и цветность.
Level ограничивает уже не набор кодировочных инструментов, а масштаб потока: сочетание разрешения, частоты кадров, битрейта, количества макроблоков, DPB и других параметров. Если целевое устройство требует определенный level, недостаточно только написать --level: фактический поток также должен укладываться в ограничения. x264 способен предупреждать о превышении, поэтому такие сообщения нельзя игнорировать при подготовке совместимого файла.
Принудительный profile может переопределить пользовательские настройки. Это сделано намеренно: обещание совместимости важнее отдельного флага. Если после добавления --profile baseline исчезли CABAC или B-кадры, это не ошибка, а следствие спецификации выбранного профиля.
| Профиль | Допустимая идея | Ключевое ограничение |
|---|---|---|
| baseline | Максимально простой AVC-поток. | Нет CABAC и B-кадров; нет 8x8 DCT. |
| main | Более эффективный поток, чем baseline. | Нет 8x8 DCT; lossless не допускается. |
| high | Распространенный 8-битный профиль с 8x8 transform. | Не предназначен для lossless в режиме profile restriction. |
| high10 | До 10 бит. | Приемник должен декодировать High 10; совместимость бытовых устройств ниже. |
| high422 | До 10 бит, 4:2:0/4:2:2. | Требуется соответствующий профессиональный декодер. |
| high444 | До 10 бит и 4:4:4, допускает более широкий набор. | Наименее универсален среди перечисленных профилей. |
GOP, ключевые кадры и смены сцен
--keyint задает максимальный интервал между ключевыми точками GOP, а --min-keyint — минимальный. При обычном файловом кодировании x264 дополнительно анализирует смены сцен и может вставлять I/IDR-кадры раньше максимального интервала. За агрессивность отвечает --scenecut; --no-scenecut полностью отключает такое решение.
Короткий GOP облегчает произвольный доступ и может быть нужен для сегментации, вещания и монтажных требований, но увеличивает долю дорогих intra-кадров. Слишком длинный GOP улучшает эффективность на спокойном материале, однако ухудшает точность перемотки/сегментации и может нарушить требования платформы. Поэтому keyint выбирают из требований к частоте кадров, длине сегмента и декодеру, а не только из желания уменьшить файл.
--open-gop разрешает использовать recovery points и связи через границы GOP, повышая эффективность в некоторых сценариях, но снижая простоту независимого доступа к сегментам. --intra-refresh вместо периодического полного IDR распределяет обновление области кадра по времени; это полезно в отдельных потоковых системах, но поддержка должна быть согласована с приемной стороной.
B-кадры, reference frames и weighted prediction
B-кадры позволяют предсказывать содержимое по соседним опорным кадрам и обычно заметно повышают эффективность сжатия. --bframes ограничивает их максимальное число подряд, а --b-adapt выбирает способ принятия решения о расположении B-кадров. Значение 2 выполняет более дорогой поиск и особенно заметно замедляется при большом допустимом числе B-кадров.
--b-pyramid разрешает части B-кадров самим становиться ссылочными. Режим normal эффективнее, но справка x264 отдельно предупреждает, что он не совместим с Blu-ray. strict строит строго иерархическую пирамиду. Такие параметры нельзя рассматривать только через призму качества: они напрямую связаны с декодерными требованиями и структурой потока.
--ref задает число reference frames. Больше ссылок расширяет выбор для motion compensation, но увеличивает вычисления и потребление DPB на стороне декодера. На высоких разрешениях и при ограниченном level чрезмерное --ref может сделать поток несовместимым с формальными пределами. Поэтому preset обычно является лучшей исходной точкой, чем ручное выставление максимума.
Weighted prediction помогает при плавных изменениях яркости и похожих ситуациях. --weightp управляет P-кадрами, а --no-weightb отключает взвешивание B-кадров. Отключать эти инструменты имеет смысл в основном ради конкретной совместимости или fastdecode, а не как универсальный способ ускорения.
Motion estimation, partitions и subme
Одна из самых затратных частей кодирования — поиск похожих областей между кадрами. --me выбирает алгоритм целочисленной оценки движения: dia — быстрый diamond, hex — стандартный hexagonal, umh — более глубокий uneven multi-hexagon, esa — exhaustive search, tesa — еще более дорогой вариант с Hadamard. Самый тяжелый поиск не гарантирует заметный выигрыш на каждом источнике; его цена быстро растет.
--merange задает максимальный радиус поиска движения. Большое значение может помочь при действительно крупных смещениях, но увеличивает время. Preset already связывает метод и радиус с остальными параметрами, поэтому ручное увеличение merange без анализа часто дает небольшой эффект.
--subme отвечает за субпиксельную оценку и глубину mode decision. По мере роста значения x264 переходит от простых SAD/SATD решений к RD-поиску, затем к RD refinement и, на верхних уровнях, к QP-RD и отключению ранних отсечений. Значения 10 и 11 особенно дороги; 10 требует trellis=2 и включенного AQ.
--partitions определяет, какие размеры блоков рассматривать для I-, P- и B-кадров. Мелкие блоки лучше описывают сложные границы и неоднородное движение, но расширяют пространство поиска и увеличивают служебные решения. В veryslow включаются все partitions, тогда как быстрые пресеты сознательно ограничивают набор.
| Параметр | Варианты | Что меняет |
|---|---|---|
--me | dia, hex, umh, esa, tesa | Глубину целочисленного поиска движения. |
--merange | целое число | Максимальный радиус motion vectors. |
--subme | 0–11 | Субпиксельный поиск и глубину RD mode decision. |
--partitions | p8x8, p4x4, b8x8, i8x8, i4x4, none, all | Набор вариантов разбиения макроблока, рассматриваемых анализатором. |
--direct | none, spatial, temporal, auto | Режим direct motion vectors в B-кадрах. |
--no-mixed-refs | флаг | Запрещает выбирать разные reference frames для отдельных partitions. |
--no-chroma-me | флаг | Исключает цветность из оценки движения, ускоряя анализ ценой потенциальной эффективности. |
Психовизуальные оптимизации и deblocking
x264 известен тем, что оптимизирует не только математическую ошибку, но и субъективное восприятие. --psy-rd управляет силой психовизуальной RD-оптимизации и psy-trellis. Эти механизмы сознательно могут ухудшать PSNR и SSIM, если структура изображения при этом выглядит естественнее человеку. Поэтому сравнивать обычный preset с настройкой --tune psnr только по цифрам метрики некорректно: цели различаются.
--no-psy полностью отключает такие оптимизации. Это нужно для лабораторных сравнений или специальных пайплайнов, но обычно не является улучшением для обычного просмотра. Схожая логика относится к --tune psnr и --tune ssim: они нужны, когда именно метрика является критерием эксперимента.
Deblocking — встроенный loop filter H.264. --deblock alpha:beta меняет силу фильтра, а --no-deblock отключает его. Слишком сильное положительное смещение способно сгладить мелкую фактуру, слишком отрицательное — оставить более резкие границы блоков. Preset и tune уже задают разумную основу; ручная корректировка оправдана, когда есть конкретный визуальный дефект и известный тип материала.
AQ, mb-tree, qcomp и распределение качества
Adaptive Quantization перераспределяет качество внутри кадра. --aq-mode 1 использует variance AQ, режим 2 — auto-variance, режим 3 добавляет смещение в пользу темных сцен. --aq-strength управляет силой эффекта. При слишком слабом AQ плоские и темные области могут выглядеть хуже, чем предполагает средний QP; слишком сильный AQ способен забирать чрезмерно много битов у других областей.
MB-tree отслеживает, насколько текущие блоки будут полезны как предсказание будущих кадров, и учитывает это при распределении битов. --no-mbtree отключает механизм; быстрые или низколатентные режимы делают это ради скорости и задержки. В обычном файловом кодировании mb-tree — одна из причин не копировать вручную быстрые параметры в медленный preset.
--qcomp задает компрессию кривой QP и тем самым влияет на то, насколько сильно качество меняется между простыми и сложными сценами. --cplxblur и --qblur сглаживают колебания до и после компрессии кривой. Это уже тонкая зона настройки rate control: менять значения стоит только при понимании, какую конкретно проблему нужно исправить.
--zones позволяет задать участки по номерам кадров и либо принудительный QP, либо множитель битрейта. --qpfile способен закреплять типы кадров и QP для отдельных позиций. Эти инструменты нужны для сегментных сценариев, повторяемой расстановки ключевых кадров и специальных энкодинг-процессов, а не как универсальный способ улучшить сцену.
Trellis, transform и квантовочные матрицы
--trellis включает RD-квантование: 0 отключает его, 1 применяет на финальном кодировании макроблока, 2 — при всех mode decisions. Более высокий режим повышает вычислительную цену и используется медленными пресетами. В сочетании с высоким subme он может улучшать распределение коэффициентов, но бессмысленно оценивать его отдельно от общего preset.
--no-8x8dct отключает адаптивный 8×8 transform. Это обязательно для некоторых профилей и быстрых пресетов. --no-dct-decimate запрещает удаление малозначимых коэффициентов в P-кадрах; tune grain использует подобные изменения, чтобы лучше сохранять высокочастотную структуру.
Параметры --cqm, --cqmfile и семейство --cqm4*/--cqm8* управляют quantization matrices. x264 умеет flat и JVT presets, а также пользовательские матрицы. Это продвинутый инструмент: неверная матрица легко ухудшит распределение ошибок и совместимость, поэтому современная практическая настройка чаще опирается на CRF/preset/tune, чем на ручное составление матриц.
8/10 бит, 4:2:0, 4:2:2, 4:4:4 и RGB
Современные сборки x264 могут поддерживать 8- и 10-битный вывод, а при конфигурации с расширенной цветностью — i420, i422, i444 и RGB. Конкретный набор определяет сборка и выбранный profile. --output-depth задает глубину вывода, --output-csp — цветовое представление. Для raw-входа отдельно задаются --input-depth и --input-csp.
10-битное кодирование полезно не только для HDR. Более точное квантование внутренних значений способно уменьшать banding и повышать эффективность на некоторых материалах, но совместимость декодеров с High 10 заметно ниже, чем с обычным High 8-bit 4:2:0. Для массовой доставки важно сначала проверить требования целевых устройств, а затем выбирать глубину.
4:2:2 и 4:4:4 сохраняют больше цветовой информации, но требуют соответствующих H.264 профилей и декодеров. Они востребованы в профессиональных цепочках и промежуточных мастер-файлах, тогда как бытовая совместимость почти всегда ориентирована на 4:2:0. Перевод 4:2:0-источника в 4:4:4 сам по себе не восстанавливает утраченную цветовую детализацию.
| Ключ | Пример | Смысл |
|---|---|---|
--input-csp | i420, i422, i444, rgb | Как трактовать цветовые компоненты входа. |
--input-depth | 8, 10, 16 | Точность raw-входа. |
--output-csp | i400, i420, i422, i444, rgb | Формат кодируемого потока, если профиль и сборка допускают. |
--output-depth | 8 или 10 | Глубина кодируемого потока. |
--profile high10 | профиль | Ограничивает поток правилами High 10. |
--profile high422 | профиль | Разрешает 4:2:2 в пределах профиля. |
--profile high444 | профиль | Нужен для 4:4:4 и наиболее широкого набора цветности. |
Встроенные видеофильтры x264
CLI x264 имеет небольшой набор встроенных фильтров, но это не монтажная система. Через --vf можно последовательно применить crop, resize и select_every. Для сложного деинтерлейса, восстановления, шумоподавления, тонального преобразования или многоступенчатой цветокоррекции обычно используют внешнюю фильтрацию и передают уже подготовленный поток в x264.
Фильтр crop принимает значения left, top, right, bottom и физически удаляет пиксели по краям. Resize задает ширину/высоту, SAR, fit-to-box, цветовое пространство и метод ресэмплинга. Среди методов в справке перечислены fastbilinear, bilinear, bicubic, point, area, gauss, sinc, lanczos, spline и другие, если соответствующая библиотека сборки это поддерживает.
select_every выбирает кадры по повторяющемуся шаблону: указывается длина шага и смещения внутри него. Это технический фильтр для регулярной выборки кадров; он не заменяет полноценный анализ телесина или деинтерлейс.
# Обрезать 8 пикселей слева/справа и 4 сверху/снизу
x264 --vf crop:8,4,8,4 --crf 20 -o cropped.264 input.y4m
# Изменить размер
x264 --vf resize:1280,720 --crf 20 -o hd.264 input.y4mSAR, FPS, CFR и временная база
--sar width:height записывает Sample Aspect Ratio — отношение сторон отдельного пикселя. Это не то же самое, что разрешение кадра. Например, анаморфный материал может иметь 720×576 пикселей, но отображаться в ином соотношении сторон благодаря SAR. Неправильный SAR приводит к растянутому или сжатому изображению даже при технически корректном кодировании.
--fps задает частоту кадров; рациональная запись вроде 24000/1001 предпочтительнее округленного 23.976, когда важна точная временная база. --force-cfr принудительно генерирует постоянную частоту временных меток. Для переменного времени существуют --tcfile-in, --tcfile-out и --timebase. Не следует использовать force-cfr механически: если источник действительно VFR и сохранение временной структуры критично, нужно работать с timecode осознанно.
--dts-compress устраняет начальную задержку с помощью контейнерного приема DTS. Это специализированная опция и не является универсальным способом исправить синхронизацию. Проблемы A/V sync часто возникают раньше — на этапе декодирования, фильтрации, неверной интерпретации VFR или отдельного аудиоконвейера, который x264 вообще не контролирует.
VUI и цветовая метаинформация
Параметры VUI не перекрашивают уже подготовленные пиксели. Они описывают потоку, как декодер должен трактовать диапазон, цветовые примарии, передаточную функцию, матрицу и расположение chroma samples. Это фундаментальное различие: если исходные значения были конвертированы неправильно, запись --colormatrix bt709 не выполнит обратную цветокоррекцию, а лишь сообщит метку.
--range tv|pc задает сигнализацию ограниченного или полного диапазона. --colorprim, --transfer и --colormatrix описывают цветовое пространство. Для типичного HD SDR часто встречается связка bt709/bt709/bt709, но использовать ее автоматически нельзя: реальные метаданные и преобразования должны соответствовать источнику и цели.
x264 также поддерживает поля --mastering-display, --cll и --alternative-transfer. Это позволяет поместить HDR-связанную SEI/VUI-информацию в AVC-поток, однако наличие метаданных не делает 8-битный SDR-источник HDR и не заменяет цветовое преобразование. Вся цепочка должна быть согласована: пиксельные значения, transfer, primaries, matrix, range и возможности проигрывателя.
| Параметр | О чем сообщает |
|---|---|
--range | Полный или телевизионный диапазон уровней. |
--colorprim | Координаты цветовых примарий. |
--transfer | Передаточная характеристика, включая варианты BT.2020, PQ и HLG. |
--colormatrix | Матрица преобразования между luma/chroma и RGB. |
--chromaloc | Положение выборок цветности. |
--mastering-display | Координаты примарий/белой точки мастер-дисплея и яркость. |
--cll | MaxCLL и MaxFALL. |
--overscan | Рекомендация show/crop для overscan. |
--videoformat | Сигнализация component/PAL/NTSC/SECAM/MAC/undef. |
Интерлейс, pulldown и frame packing
--tff и --bff включают интерлейсный режим с соответствующим порядком полей. Это не деинтерлейс: x264 принимает уже правильно организованный интерлейсный материал и кодирует его с учетом полевой структуры. Если прогрессивный контент ошибочно пометить как interlaced, качество и совместимость могут ухудшиться; если интерлейсный источник предварительно нужно превратить в progressive, для этого требуется внешний деинтерлейсер.
--pulldown добавляет soft pulldown для заданных схем, включая 22, 32, 64, double, triple и euro, при CFR-входе. Такой режим полезен в строго определенных телевизионных/дисковых сценариях, но не заменяет корректную обработку телесина на этапе подготовки исходника.
--fake-interlaced помечает прогрессивный поток как interlaced, при этом фактически кодирует progressive. Справка x264 прямо указывает применение для 25p и 30p Blu-ray. Использовать этот флаг без требования формата не следует.
Для стереоскопического видео --frame-packing записывает тип расположения двух представлений: checkerboard, чередование колонок или строк, side-by-side, top-bottom, frame alternation и другие. Это метаданные структуры; сам параметр не создает второе представление и не преобразует 2D в 3D.
Blu-ray, AVC-Intra и stitchable-сегменты
--bluray-compat включает набор ограничений и совместимых решений для Blu-ray. Одного флага недостаточно для готового дискового потока: разрешение, частота кадров, уровень, VBV, GOP, число slices и остальные параметры должны соответствовать целевому профилю авторинга. x264 лишь обеспечивает кодировочную часть, а структура диска и мультиплексирование выполняются другими инструментами.
--avcintra-class и --avcintra-flavor предназначены для AVC-Intra совместимости, включая классы 50, 100, 200, 300 и 480 и варианты flavor panasonic/sony. Это профессиональный режим, где особенно важно соблюдать требования контейнера, кадровой структуры и метаданных конкретной системы.
--stitchable запрещает оптимизировать заголовки на основе содержимого так, чтобы независимо закодированные сегменты можно было надежно объединять. Флаг полезен в распределенном/сегментном кодировании, но одинаковые GOP, SPS/PPS, цветовые и rate-control параметры все равно должны проектироваться согласованно.
Низкая задержка и tune zerolatency
Задержка x264 складывается не только из времени вычислений одного кадра. Lookahead, B-кадры и reorder требуют буферизации будущих кадров, а потоковая цепочка добавляет собственные очереди. --tune zerolatency поэтому отключает B-кадры и mb-tree, обнуляет rc-lookahead и sync-lookahead, включает sliced threads и force-cfr. В результате снижается алгоритмическая задержка, но компрессионная эффективность падает.
Для интерактивной трансляции часто используют быстрый preset, zerolatency и VBV. Однако эти три вещи решают разные задачи: preset определяет вычислительную сложность, zerolatency — буферизацию внутри кодировщика, VBV — допустимый поток для канала и декодера. Нельзя заменить одно другим.
--sliced-threads обеспечивает низколатентное распараллеливание внутри кадра, но справка прямо отмечает более низкую эффективность. Обычный frame threading лучше использует межкадровую структуру, но создает дополнительную задержку. Для файла sliced threads без требования latency чаще не нужен.
# Концептуальный пример низкой задержки
x264 --preset veryfast --tune zerolatency --bitrate 3500 --vbv-maxrate 3500 --vbv-bufsize 3500 -o live.264 input.y4mПотоки, CPU и воспроизводимость результата
x264 автоматически использует многопоточность, но --threads позволяет задать число потоков вручную. --lookahead-threads отдельно регулирует параллелизм анализа будущих кадров. Больше потоков не всегда означает линейное ускорение: часть решений зависит от соседних кадров и строк, а на небольшом разрешении избыточная синхронизация может съесть выгоду.
--sync-lookahead задает буфер кадров для многопоточного lookahead. В low-latency конфигурации он обычно обнуляется. --thread-input запускает AviSynth в отдельном потоке, что иногда полезно, если фильтрация и кодирование могут перекрываться по времени.
--non-deterministic разрешает небольшое улучшение качества SMP ценой точной повторяемости. Напротив, --cpu-independent старается обеспечить идентичный результат на разных CPU, не позволяя архитектуре выбирать разные алгоритмические варианты. Это важно для распределенных пайплайнов, где битовая идентичность между узлами ценнее небольшого выигрыша.
--asm и --no-asm управляют SIMD-оптимизациями. Отключение ASM резко снижает производительность и обычно нужно только для диагностики, разработки или сравнения эталонного C-кода. В обычном кодировании следует позволить x264 определить доступные CPU-инструкции самостоятельно.
В справке также присутствует OpenCL. Он не превращает x264 в полноценный GPU-видеокодировщик: аппаратная архитектура x264 остается CPU-ориентированной, а OpenCL используется лишь для отдельных вычислений при соответствующей сборке. Если нужна именно аппаратная H.264-кодировка NVENC/QSV/AMF, это другой класс энкодеров с иными алгоритмами, задержкой и качеством на бит.
Выход: raw H.264, MKV, FLV и MP4
Тип выхода x264 может определяться расширением файла или --muxer. Базовый и самый переносимый результат — raw bytestream с расширением .264. Он содержит только AVC-видео без аудио и сложных контейнерных данных. Для дальнейшей сборки в MKV/MP4 такой поток удобно передавать внешнему muxer.
Справочный вывод x264 перечисляет MKV и FLV, а MP4 доступен только если бинарник собран с соответствующей поддержкой GPAC или L-SMASH. Поэтому команда, успешно создающая MP4 в одной сборке, может быть недоступна в другой. Перед автоматизацией лучше один раз проверить --help и зафиксировать сборочные возможности.
--aud добавляет access unit delimiters, --sps-id задает идентификаторы SPS/PPS. Такие параметры важны в некоторых транспортных и вещательных цепочках. Менять их без требований последующего muxer/decoder не требуется.
Логи, прогресс и статистика после кодирования
Во время работы x264 выводит скорость, количество обработанных кадров, оценку оставшегося времени и текущий размер. После завершения появляется подробная статистика: число I/P/B-кадров, средний QP, размеры, распределение macroblock partitions, использование transform 8×8, direct motion vectors, weighted P-frames, reference frames и итоговый kb/s. Этот отчет полезнее одной цифры fps, потому что помогает понять, действительно ли применились ожидаемые параметры.
-v или --verbose печатает статистику для каждого кадра. --log-level ограничивает уровень сообщений: none, error, warning, info, debug. --quiet минимизирует вывод, --no-progress убирает строку прогресса, сохраняя итоговые сообщения. Для автоматического сервера разумно не подавлять warnings полностью: именно там видны превышение level, проблемы VBV и несовместимые настройки.
--psnr и --ssim включают расчет соответствующих метрик. Их следует трактовать как технические измерения, а не абсолютную оценку визуального качества. Психовизуальные инструменты x264 специально оптимизируют восприятие и могут ухудшить PSNR/SSIM, поэтому для лабораторного сравнения метрик используют tune psnr/ssim и фиксируют все остальные условия.
На реальном процессе x264 в консоли отображаются входные сведения, выбранный профиль и level, CPU-возможности, полный набор примененных внутренних параметров и строка прогресса. Именно этот вывод помогает отличить фактически запущенную конфигурацию от той, которую пользователь предполагал получить.
Работа через pipe и автоматизация
Для сложной подготовки входа x264 удобно ставить в конец конвейера. Декодер или фильтровая система выводит Y4M/raw в стандартный вывод, x264 читает - как стандартный ввод и формирует AVC. Это позволяет не создавать огромный временный несжатый файл. При raw-потоке нужно дополнительно передать разрешение, цветность, глубину и fps; Y4M переносит эти сведения в заголовке.
Двухпроходное кодирование через pipe требует осторожности. Второй проход должен получить в точности ту же последовательность кадров, что первый, с теми же временными и фильтровыми преобразованиями. Если upstream-процесс недетерминирован, меняет число кадров или имеет случайный шум, статистика первого прохода перестанет точно соответствовать второму.
В пакетном файле или shell-скрипте полезно явно проверять код завершения x264 и наличие результата, а не считать закрытие окна успехом. Также стоит хранить фактическую командную строку рядом с результатом. Она является более надежным описанием настроек, чем вручную заполненная таблица параметров, особенно если preset и tune расширяют десятки внутренних опций.
# Пример чтения Y4M из stdin
producer --y4m-output - | x264 --crf 20 --preset slow -o output.264 -
# Для raw нужно явно описать поток
producer --raw-output - | x264 --demuxer raw --input-res 1920x1080 --input-csp i420 --fps 24000/1001 --crf 20 -o output.264 -Практические сценарии настройки
Файловое кодирование без жесткого размера
Начните с CRF и preset medium/slow. Не задавайте вручную ref, bframes, me, subme и trellis, пока не появится конкретная причина. Сначала добейтесь правильного входа, цветовых метаданных, профиля и воспроизведения, затем сравните соседние CRF на сложных сценах. Такой порядок отделяет визуальную цель от микрооптимизаций.
x264 --preset slow --crf 20 --profile high -o movie.264 movie.y4mФайл с заданным средним битрейтом
Если размер жестко ограничен, используйте два прохода и один stats-файл. Первый проход можно писать в NUL или /dev/null в зависимости от системы, второй — в конечный AVC. Оба прохода должны видеть одинаковый вход. Если на втором изменился crop, fps или число кадров, статистика станет несогласованной.
Ограниченный канал или устройство
Сначала выясните профиль, level, maxrate и bufsize целевой системы. Затем задавайте VBV вместе с требуемым profile/level и проверяйте warnings. Средний bitrate сам по себе не защищает от пиков. Для сегментной доставки также согласуйте keyint со временем сегмента.
Материал с зерном
Попробуйте tune grain и сравните с обычным режимом на полном размере. Grain намеренно сохраняет высокочастотную структуру и способен резко увеличить битрейт при том же CRF. Если итоговый размер слишком велик, подберите CRF заново; не пытайтесь одновременно компенсировать tune десятком случайных параметров.
Минимальная задержка
Используйте zerolatency как основу, быстрый preset и VBV, соответствующий каналу. Проверьте, что upstream и muxer не добавляют собственные большие буферы. Низкая задержка — свойство всей цепочки, а не одного флага x264.
Типичные ошибки и способы исправления
| Симптом | Вероятная причина | Что проверить |
|---|---|---|
| x264 сразу завершается | Вход не открывается, неверный параметр, неподдерживаемый demuxer. | Запустить из уже открытого терминала, чтобы увидеть error; проверить --help и путь к файлу. |
| Raw выглядит как мусор | Неверные input-res, input-csp или глубина. | Сверить точный формат производителя raw-потока и порядок плоскостей. |
| AviSynth не открывается | Разрядность x264/AviSynth/plugins не совпадает или AVS support отсутствует. | Проверить архитектуру всех компонентов и строку поддержки в --help. |
| MP4 не создается | Сборка x264 не содержит GPAC/L-SMASH muxer. | Писать raw .264 и мультиплексировать отдельно либо использовать сборку с нужной поддержкой. |
| Поток не играет на устройстве | Profile/level/VBV/цветность/глубина превышают возможности декодера. | Сверить требования устройства, а не только расширение файла. |
| Предупреждение level limit | Фактические параметры превышают ограничения выбранного level. | Снизить fps/разрешение/битрейт/ref либо выбрать разрешенный level, если устройство поддерживает. |
| В сложных сценах резко падает качество | VBV слишком жесткий для заданного содержания и канала. | Проверить maxrate/bufsize, целевой bitrate и соответствие профилю доставки. |
| Размер при CRF неожиданно большой | Сложный/шумный источник, медленный preset, tune grain, высокий fps или разрешение. | Сравнить короткие тесты и поднять CRF; не ожидать фиксированного размера от CRF. |
| Кодирование слишком медленное | Слишком тяжелый preset, tesa, высокие subme/ref/merange или фильтрация upstream. | Вернуться к preset без ручных overrides и измерить скорость по этапам. |
| Цвета выглядят неправильно | Неверное преобразование диапазона/матрицы до x264 или ложные VUI-метки. | Проверить фактический pixel pipeline; помнить, что VUI не перекрашивает кадры. |
| Banding на градиентах | Сильное квантование, 8-битный pipeline, предыдущая обработка уже повредила градиент. | Сравнить меньший CRF и, если цепочка допускает, 10-битное кодирование. |
| Первый и второй pass расходятся | Вход между проходами изменился или stats-файл не тот. | Зафиксировать одинаковый фильтровый скрипт, fps, crop, число кадров и путь --stats. |
| Сегменты плохо стыкуются | Разные заголовки или GOP-параметры. | Использовать согласованную конфигурацию и при необходимости --stitchable. |
| Нужен CBR, но размер плавает | Обычный ABR/VBV — не жесткий CBR. | Разобраться с nal-hrd cbr/filler и ограничениями контейнера целевой системы. |
| PSNR ниже после psy | Психовизуальная оптимизация жертвует метрикой ради восприятия. | Для лабораторного PSNR использовать tune psnr и одинаковые условия сравнения. |
Почему неизвестная опция часто означает чужой синтаксис
У FFmpeg, HandBrake, x265 и x264 есть похожие по смыслу параметры, но синтаксис не взаимозаменяем. Например, -pix_fmt — ключ FFmpeg, а x264 использует --input-csp/--output-csp. Ошибка возникает, когда команду из одного инструмента вставляют в другой. Проверяйте --fullhelp конкретной программы и не переносите параметры по внешнему сходству названий.
Почему закрывающееся окно нужно заменить обычным терминалом
Если запускать batch-файл двойным щелчком, консоль исчезает сразу после ошибки и сообщение невозможно прочитать. Для диагностики откройте cmd/PowerShell/terminal вручную, перейдите в каталог и выполните ту же строку. В batch можно временно добавить паузу после x264, но в автоматизации правильнее проверять exit code и писать stdout/stderr в лог.
Подробный справочник ключевых параметров
Ниже собраны параметры, которые чаще всего встречаются в реальных x264-командах. Таблица не заменяет --fullhelp конкретного бинарника: часть входных модулей, muxer и глубин зависит от сборки. Она нужна как карта взаимосвязей, чтобы было понятно, какой блок кодировщика меняет каждый ключ.
| Ключ | Функция | Замечание |
|---|---|---|
--help / --longhelp / --fullhelp | Уровни встроенной справки. | Начинать с них при любой новой сборке: они показывают не только синтаксис, но и собранные входы/выходы. |
--profile | Принудительные ограничения H.264 profile. | Использовать ради совместимости; помнить, что profile может переопределить другие опции. |
--level | Сигнализация и проверка Annex A level. | Задавать по требованиям приемника и следить за предупреждениями о превышениях. |
--preset | Связанный набор параметров скорость/эффективность. | Главный регулятор вычислительной сложности; не дублировать весь preset ручными ключами без причины. |
--tune | Дополнительная настройка под источник или режим. | film/animation/grain/stillimage — психовизуальные; fastdecode/zerolatency — технические. |
--slow-firstpass | Отключает ускорения pass 1. | Редкая опция для экспериментов; обычно быстрый первый проход достаточно точен для ratecontrol. |
--keyint | Максимальный GOP. | Согласовывать с сегментацией, seek и требованиями формата. |
--min-keyint | Минимальный интервал ключевых кадров. | Не дает scenecut вставлять ключевые кадры слишком близко друг к другу. |
--scenecut | Чувствительность к смене сцен. | Высокое значение охотнее ставит I-frame на резких переходах. |
--no-scenecut | Отключает адаптивные I-frame на сменах сцен. | Нужен для строго фиксированной структуры GOP, но может ухудшать эффективность на реальных монтажных склейках. |
--intra-refresh | Периодическое intra-обновление вместо IDR. | Специализированный потоковый режим; приемник должен понимать такую структуру. |
--bframes | Максимум B-кадров между опорными. | Больше B может повышать эффективность, но добавляет задержку и вычисления. |
--b-adapt | Метод выбора B-кадров. | 2 — более оптимальный и медленный, особенно при большом bframes. |
--b-bias | Смещает решение в пользу/против B-кадров. | Тонкая настройка; обычно preset/b-adapt достаточно. |
--b-pyramid | Разрешает B-кадрам быть reference. | normal эффективен, но не совместим с Blu-ray; strict более ограничен. |
--open-gop | Открытая структура GOP с recovery points. | Повышает эффективность, но усложняет независимость сегментов. |
--no-cabac | Отключает CABAC. | Нужно для baseline/fastdecode; файл обычно становится менее эффективным. |
--ref | Число reference frames. | Повышает выбор предсказаний, но грузит CPU и DPB; ограничивается level. |
--deblock | Alpha/beta loop filter. | Корректировать умеренно и только после визуальной проверки. |
--no-deblock | Отключает loop filter. | Обычно только ради fastdecode или специальных тестов. |
--slices / --slices-max | Количество slices в кадре. | Используется в потоковых/дисковых профилях; лишние slices снижают эффективность. |
--slice-max-size | Максимальный размер slice в байтах. | Полезен для транспортных ограничений пакетов/канала. |
--slice-max-mbs / --slice-min-mbs | Границы slice в макроблоках. | Продвинутые ограничения структуры кадра. |
--tff / --bff | Интерлейсный порядок полей. | Не выполняют деинтерлейс; только кодируют уже интерлейсную последовательность. |
--constrained-intra | Constrained intra prediction. | Нужен некоторым профилям/форматам; ограничивает предсказание intra-blocks. |
--pulldown | Soft pulldown pattern. | Применять только при точно известной целевой телевизионной схеме. |
--fake-interlaced | Маркирует progressive как interlaced. | Используется для отдельных Blu-ray 25p/30p сценариев. |
--frame-packing | SEI о расположении стереопар. | Описывает уже подготовленный 3D layout, не создает 3D. |
--qp | Постоянный QP. | 0 дает lossless; прочие значения полезны для технических тестов, но CRF обычно удобнее. |
--bitrate | Целевой средний кбит/с. | Основа ABR и двухпроходного кодирования. |
--crf | Quality-based VBR. | Основной режим, когда размер не жестко фиксирован. |
--rc-lookahead | Сколько будущих кадров анализировать ratecontrol. | Больше дает больше информации, но увеличивает память/задержку/CPU. |
--vbv-maxrate | Максимальный локальный битрейт. | Ключевой параметр совместимости с каналом/декодером. |
--vbv-bufsize | Размер VBV buffer. | Определяет допустимую вариативность потока вокруг maxrate. |
--vbv-init | Начальное заполнение VBV. | Влияет на первые секунды буферной модели. |
--crf-max | Верхний предел RF при CRF+VBV. | Слишком жесткий предел способен конфликтовать с VBV. |
--qpmin / --qpmax | Границы QP. | Ограничивают ratecontrol; неправильные границы легко ухудшают способность соблюдать VBV/битрейт. |
--qpstep | Максимальный шаг QP. | Сдерживает резкие изменения квантования между решениями. |
--ratetol | Допуск ABR/VBV. | Тонкая настройка, редко нужная вне специальных профилей. |
--ipratio | Отношение QP I к P. | Меняет относительное качество ключевых кадров. |
--pbratio | Отношение QP P к B. | Меняет распределение качества между P и B. |
--chroma-qp-offset | Смещение QP цветности. | Позволяет отдельно скорректировать качество chroma. |
--aq-mode | Метод Adaptive Quantization. | 0 off, 1 variance, 2 auto-variance, 3 с bias к темным сценам. |
--aq-strength | Сила AQ. | Слишком высокое значение может чрезмерно перераспределять биты. |
--pass | Номер прохода ratecontrol. | 1 пишет stats, 2 читает; 3 — последующий проход с перезаписью stats. |
--stats | Путь к статистике pass. | Должен совпадать у связанных проходов. |
--no-mbtree | Отключает macroblock tree. | Снижает эффективность, но уменьшает lookahead-зависимость и задержку. |
--qcomp | Сжатие кривой QP. | Контролирует разницу качества между простыми и сложными участками. |
--cplxblur / --qblur | Сглаживание сложности/QP. | Влияет на плавность поведения ratecontrol. |
--zones | Локальные зоны QP/битрейт-множителя. | Для выделения участков по номерам кадров. |
--qpfile | Фиксация frametype/QP отдельных кадров. | Используют для синхронизации ключевых кадров и специальных многопроходных схем. |
--partitions | Разрешенные виды block partitioning. | all дороже; быстрые presets ограничивают список. |
--direct | Direct MV: spatial/temporal/auto. | auto анализирует, какой вариант выгоднее. |
--no-weightb | Отключает weighted B prediction. | Совместимость/fastdecode; обычно ухудшает компрессию. |
--weightp | Weighted P prediction. | 0 off, 1 weighted refs, 2 + duplicates. |
--me | Алгоритм integer motion search. | dia < hex < umh < esa/tesa по стоимости поиска. |
--merange | Радиус поиска движения. | Увеличивать только при реальной необходимости больших перемещений. |
--mvrange | Максимальная длина motion vector. | Обычно auto; ограничивается стандартом/level. |
--mvrange-thread | Буфер MV между потоками. | Низкоуровневая настройка многопоточности. |
--subme | Subpixel motion estimation/mode decision. | Один из главных регуляторов тяжести анализа; высокие уровни резко замедляют. |
--psy-rd | Сила psy RD/trellis. | Оптимизирует восприятие, не численные метрики. |
--no-psy | Отключает psy. | Нужно для PSNR/SSIM тестов или специальных экспериментов. |
--no-mixed-refs | Один reference на partition decision. | Ускоряет за счет меньшего пространства поиска. |
--no-chroma-me | Не учитывать chroma при ME. | Ускорение с потенциальной потерей эффективности на цветных границах. |
--no-8x8dct | Отключает 8×8 transform. | Нужно baseline/main и некоторым быстрым профилям. |
--trellis | RD quantization 0/1/2. | 2 дороже и используется в slow presets. |
--no-fast-pskip | Отключает раннее распознавание P-skip. | Повышает анализ, но заметно замедляет на простом материале. |
--no-dct-decimate | Не удалять малозначимые coefficients. | Помогает сохранять зерно/мелкую структуру ценой битов. |
--nr | Встроенное noise reduction. | Простой механизм, не замена специализированному денойзу. |
--deadzone-inter / --deadzone-intra | Quantization deadzones. | Редкая ручная настройка высокочастотных коэффициентов. |
--cqm / --cqmfile | Quantization matrices. | Использовать только при понимании CQM и совместимости. |
--range | VUI full/tv. | Сигнализация диапазона, а не преобразование пикселей. |
--colorprim | VUI primaries. | Должны соответствовать фактической цветовой системе. |
--transfer | VUI transfer function. | Включает bt709, PQ, HLG и другие сигналы. |
--colormatrix | VUI matrix coefficients. | Не исправляет уже неверно преобразованный YUV. |
--chromaloc | Положение chroma samples. | Нужно для точной интерпретации subsampling. |
--mastering-display | Mastering display metadata. | Только метаданные; HDR pipeline должен быть подготовлен отдельно. |
--cll | MaxCLL/MaxFALL. | Контентная световая метаинформация. |
--nal-hrd | HRD none/vbr/cbr. | Требует VBV; cbr не допускается в MP4 muxer x264. |
--filler | Filler для hard-CBR. | Использовать только если это требует транспорт/спецификация. |
--pic-struct | Picture Timing SEI. | Нужен некоторым broadcast-пайплайнам. |
--crop-rect | Bitstream-level cropping rectangle. | Не удаляет пиксели так же, как vf crop; сообщает crop в потоке. |
--output | Выходной файл. | Главный обязательный путь результата. |
--muxer | auto/raw/mkv/flv. | Набор зависит от сборки; MP4 обычно определяется расширением при наличии библиотеки. |
--demuxer | auto/raw/y4m/avs/lavf/ffms. | Набор зависит от сборки. |
--input-fmt | Принудительный input format для lavf. | Полезен при нестандартном расширении/потоке. |
--input-csp | Цветовой формат входа. | Критичен для raw; неверное значение полностью портит интерпретацию кадра. |
--output-csp | Цветовой формат AVC. | Должен соответствовать profile и требованиям декодера. |
--input-depth / --output-depth | Глубина. | Позволяют строить 8/10-битные цепочки при поддержке сборки. |
--input-range | Диапазон входа. | Описывает вход для встроенного преобразования; не путать с VUI --range. |
--input-res | Разрешение raw. | Обязательно, если размер нельзя получить из заголовка. |
--index | Файл индекса входа. | Используется соответствующим input-модулем для ускоренного/стабильного доступа. |
--sar | Sample Aspect Ratio. | Влияет на отображаемые пропорции без изменения размеров кадра. |
--fps | Частота кадров. | Лучше задавать точной дробью для NTSC-like rates. |
--seek / --frames | Диапазон кадров. | Удобны для тестовых фрагментов и отладки. |
--bluray-compat | Ограничения Blu-ray. | Требует согласования с остальными параметрами дискового профиля. |
--avcintra-class / --avcintra-flavor | AVC-Intra режимы. | Профессиональные совместимые профили Panasonic/Sony. |
--stitchable | Стабильные заголовки для склейки сегментов. | Полезен в распределенном кодировании. |
--verbose | Покадровая статистика. | Отладка; создает очень большой лог. |
--no-progress / --quiet | Сокращение консольного вывода. | Удобно в автоматизации, но warnings лучше сохранять. |
--log-level | none/error/warning/info/debug. | Регулирует детализацию диагностики. |
--psnr / --ssim | Расчет метрик. | Использовать для контролируемых тестов, не как абсолютную субъективную оценку. |
--threads | Число потоков кодирования. | Обычно auto дает хороший результат; ручная фиксация нужна для reproducibility/ограничений ресурсов. |
--lookahead-threads | Потоки lookahead. | Отдельно масштабирует анализ будущих кадров. |
--sliced-threads | Низколатентное распараллеливание slices. | Меньше задержка, ниже эффективность. |
--thread-input | Отдельный поток AviSynth input. | Может перекрыть фильтрацию и кодирование. |
--sync-lookahead | Буфер кадров lookahead. | Ноль входит в zerolatency. |
--non-deterministic | Разрешает небольшую недетерминированность SMP. | Чуть лучше оптимизация ценой точного совпадения битстрима. |
--cpu-independent | Одинаковый результат на разных CPU. | Полезно в фермах и воспроизводимых тестах. |
--asm / --no-asm | SIMD control. | Диагностика/разработка; no-asm резко медленнее. |
--opencl | OpenCL helper. | Не заменяет аппаратный H.264 encoder и зависит от сборки. |
--dump-yuv | Сохранение reconstructed frames. | Отладка, сравнение и исследование энкодера. |
--sps-id | ID SPS/PPS. | Низкоуровневая интеграция в транспортные схемы. |
--aud | Access Unit Delimiters. | Нужны некоторым потоковым/вещательным системам. |
--force-cfr | Принудительные CFR timestamps. | Использовать только при согласованной временной модели. |
--tcfile-in / --tcfile-out | Timecode input/output. | Для VFR и переноса временных меток. |
--timebase | Числитель/знаменатель временной базы. | Продвинутая работа с timestamp precision. |
--dts-compress | Сжатие начальной DTS-задержки. | Контейнерный workaround, не универсальный sync-fix. |
--vf crop | Обрезка краев. | Физически меняет кадр до кодирования. |
--vf resize | Масштабирование/SAR/CSP. | Встроенный swscale-путь с выбором метода. |
--vf select_every | Регулярная выборка кадров. | Техническая обработка по pattern step/offset. |
Как читать финальную статистику x264
Строки frame I, frame P и frame B показывают количество кадров каждого типа, средний QP и средний размер. Если B-кадров внезапно нет, хотя ожидался обычный preset, проверьте profile, tune zerolatency или явный --bframes 0. Если I-кадров слишком много, изучите keyint/scenecut и структуру исходного монтажа.
Блоки mb I, mb P и mb B показывают, какие разделения макроблоков оказались востребованы. Они полезны для исследования, но не являются целью настройки сами по себе: не нужно менять partitions только ради красивого распределения процентов. Гораздо важнее итоговая визуальная проверка и соответствие битрейту/совместимости.
Строка 8x8 transform показывает долю блоков, где применялся соответствующий transform. direct mvs отражает распределение spatial/temporal при direct auto. Weighted P-Frames показывает фактическое использование weighted prediction, а ref P/B — как распределились ссылки по спискам. Эти числа помогают подтвердить, что алгоритмы действительно были задействованы, но не дают простой шкалы лучше/хуже.
Финальный kb/s — фактический видеобитрейт результата. В режиме CRF он является следствием сложности и настроек, а не заранее обещанной величиной. В ABR/2-pass он должен быть близок к цели на достаточно длинном ролике, но короткий тест может заметно отклоняться из-за заголовков, структуры GOP и статистической длины.
Как выбирать настройки без лишних ручных параметров
- Сначала определите цель: постоянное качество, фиксированный средний битрейт, ограниченный канал или минимальная задержка.
- Проверьте вход: разрешение, fps, цветность, диапазон и декодирование без ошибок.
- Выберите preset по доступному времени. Medium — контрольная точка, slow — частый выбор для файлов, veryfast — для скорости.
- Выберите rate control: CRF для свободного размера, 2-pass bitrate для жесткого бюджета, VBV — когда есть лимит канала/декодера.
- Добавьте profile/level только из требований целевой среды.
- Добавьте tune, если материал или задача действительно соответствует его назначению.
- Только после этого корректируйте keyint, color VUI, low-latency или специальные параметры формата.
- Не трогайте me/subme/ref/trellis вручную, пока не можете сформулировать проблему, которую решаете, и способ измерить результат.
- Сохраните командную строку и лог. Это позволит повторить результат и понять, что именно было применено.
Практическая настройка CRF + VBV
CRF и VBV можно использовать вместе, когда нужна переменная скорость сжатия, но поток не должен выходить за пределы канала или декодерного буфера. В этом режиме CRF по-прежнему задает желаемое качество, а VBV становится ограничителем. На простых сценах x264 свободно держит выбранный rate factor; на тяжелых сценах, если для него потребовался бы слишком высокий локальный битрейт, кодировщик повышает квантование, чтобы не нарушить --vbv-maxrate и --vbv-bufsize.
Поэтому CRF+VBV нельзя оценивать только по номеру CRF. Два файла с одинаковым CRF, но разным maxrate могут выглядеть по-разному именно на пиках сложности. Если качество резко проседает только в дыме, конфетти, воде, зерне или панорамировании, сначала проверьте VBV: возможно, rate control упирается в потолок и уже не может выделить сцене столько битов, сколько запросил бы свободный CRF.
Размер буфера определяет, насколько долго поток может отклоняться от среднего локального темпа. Маленький буфер заставляет кодировщик быстро реагировать на всплески сложности и сильнее ограничивает отдельные кадры. Большой буфер дает больше свободы, но должен соответствовать реальному приемнику. В потоковой доставке нельзя просто ставить огромное значение для качества, если спецификация клиента предполагает меньший decoder buffer.
x264 --crf 21 --preset slow --vbv-maxrate 6000 --vbv-bufsize 12000 --profile high --level 4.1 -o constrained.264 input.y4mВ такой строке --level 4.1 не заменяет VBV и не рассчитывает его за пользователя. Level задает формальные пределы стандарта, а конкретная платформа может требовать еще более жесткий bitrate/buffer. Поэтому параметры доставки лучше брать из документации сервиса или устройства.
Как подбирать GOP для сегментов и потоковой доставки
Для сегментной доставки важен не только средний битрейт, но и предсказуемые точки независимого входа. Если сегмент должен начинаться с независимого IDR через фиксированный интервал, --keyint обычно связывают с частотой кадров и длительностью сегмента. Например, при 25 кадр/с и двухсекундном GOP максимальный интервал составляет 50 кадров; при 30000/1001 и двух секундах — около 60 кадров. Сам x264 не создает HLS/DASH-манифесты, но структура его GOP определяет, сможет ли внешний сегментатор резать поток по удобным границам.
Для действительно фиксированных точек мало одного --keyint: scenecut способен поставить ключевой кадр раньше. Это обычно хорошо для файлового качества, но может мешать строгой сетке сегментов. В таких системах либо отключают scenecut, либо используют qpfile/внешнее управление ключевыми кадрами, чтобы все варианты bitrate имели совпадающие границы. Последнее особенно важно для adaptive bitrate: клиент должен переключаться между представлениями на синхронных точках.
Слишком частые IDR увеличивают служебную цену, потому что intra-кадр кодируется без межкадрового предсказания. Слишком редкие ухудшают перемотку и увеличивают путь восстановления после потери данных. Поэтому GOP — компромисс между эффективностью, задержкой, seek и архитектурой доставки, а не универсальное 250 всегда правильно.
Разница между crop, crop-rect, SAR и resize
В x264 есть несколько параметров, которые внешне связаны с геометрией, но действуют по-разному. --vf crop физически удаляет пиксели до кодирования. --crop-rect записывает прямоугольник обрезки на уровне битстрима: закодированные размеры и структура могут оставаться больше, а проигрывателю сообщается, какую область отображать. --sar вообще не удаляет пиксели — он меняет форму пикселя при отображении. Resize, напротив, пересчитывает сами пиксели в новое разрешение.
Из-за этой разницы одинаковый видимый результат может иметь разные технические свойства. Физический crop уменьшает объем данных, которые кодируются, и может помочь уложиться в разрешение/level. Bitstream crop не обязательно снижает вычисления и должен поддерживаться декодером корректно. SAR сохраняет исходную сетку, что полезно для анаморфного материала, но требует правильной интерпретации контейнером и проигрывателем.
Если цель — стандартный 1920×1080 progressive 1:1, проще подготовить такой кадр до x264 и явно установить SAR 1:1. Если же workflow должен сохранить исходную анаморфную геометрию, лучше не делать лишний resize: достаточно корректного SAR, если целевая система это допускает.
Диапазон уровней: input-range и VUI range
--input-range и --range часто путают. Первый относится к тому, как x264 должен трактовать входные уровни, особенно когда встроенный путь преобразует цветовое пространство. Второй — это VUI-сигнализация готового AVC-потока. Теоретически они могут иметь разные значения, если между входом и выходом выполняется реальное преобразование диапазона, но простая смена VUI-метки не делает такого преобразования.
Типичная ошибка выглядит так: источник фактически имеет full-range уровни, а его помечают как tv-range без пересчета. Декодер затем растягивает/сжимает не те значения, и черный/белый уровни выглядят неверно. Обратная ошибка дает вымытый или чрезмерно контрастный результат. Исправлять это нужно в точке, где выполняется преобразование пикселей, а не только метаданными.
То же относится к matrix/primaries/transfer. Если YUV был рассчитан как BT.601, а в VUI записать BT.709, пиксели не преобразуются автоматически. Для надежного pipeline сначала приводят данные к нужной системе, затем записывают соответствующую метку.
Проверка пресетов без ложных выводов
Сравнивать presets нужно при одинаковой цели rate control. Если сравнить ultrafast CRF 20 и slow CRF 23, невозможно понять, что именно дало разницу: preset или CRF. Для оценки компрессионной эффективности берут один и тот же CRF либо один и тот же bitrate/2-pass, одинаковый вход и одинаковую цветовую цепочку. Важно также использовать достаточно длинный материал с несколькими типами сцен, а не один статичный кадр.
Одна только скорость fps тоже не показывает ценность пресета. Более медленный режим тратит CPU на поиски, которые могут уменьшить размер при сопоставимом качестве, но величина эффекта зависит от материала. На простой презентации тяжелый motion search почти не востребован; на сложном движении он может использоваться чаще. Поэтому полезно фиксировать три показателя: время кодирования, размер/битрейт и визуальный результат или выбранную метрику.
Нельзя считать placebo самым качественным в бытовом смысле. При заданном CRF он в основном ищет более эффективное представление, а не повышает целевой уровень качества. На многих источниках прирост относительно veryslow мал, тогда как время растет резко. Preset — это вопрос экономической эффективности CPU, а не шкала от плохой картинки к хорошей.
Сборка команд для 10-битного потока
Для 10-bit важно разделять глубину входа и выхода. Если внешний фильтр выдает 16-битный контейнер значений, --input-depth описывает, как читать эти данные, а --output-depth 10 задает глубину кодируемого AVC. Если исходный raw реально 8-битный, ложное указание 10/16 бит приведет к неправильной интерпретации байтов.
Далее выбирается профиль. Для 10-bit 4:2:0 обычно требуется High 10; для 4:2:2 — High 4:2:2; для 4:4:4 — High 4:4:4. Даже если x264 успешно создал поток, целевой проигрыватель должен уметь его декодировать. Многие телевизоры, браузерные пути и аппаратные H.264-декодеры ориентированы на 8-bit High 4:2:0, поэтому 10-bit x264 часто используется в контролируемых программных цепочках, а не для максимальной бытовой совместимости.
Если 10-bit выбран ради уменьшения banding, надо помнить о всей цепочке. Перевод уже поврежденного 8-bit файла в 10-bit не возвращает потерянные градации. Польза выше, когда фильтрация и промежуточная обработка сохраняют большую точность до финального кодирования.
Внешняя фильтрация перед x264
Встроенные crop/resize/select_every покрывают только базовые операции. Для деинтерлейса, inverse telecine, denoise, deband, subtitle burn-in, сложного resize, цветового преобразования и HDR-тонмаппинга практичнее использовать AviSynth, VapourSynth, FFmpeg filters или другой внешний слой, а x264 оставить последним кодировочным этапом. Это упрощает диагностику: фильтровая часть отвечает за пиксели, x264 — за AVC.
Лучший промежуточный формат зависит от задачи. Y4M удобно передает геометрию и fps текстовым заголовком, но поддерживает не все произвольные комбинации форматов. Raw более универсален, но требует точного описания. AviSynth дает frame-server модель на Windows и не создает огромный несжатый файл. При любом подходе важно, чтобы первый и второй pass получали абсолютно одинаковые кадры.
При фильтрации цвета особенно полезно хранить метаданные рядом с командой. Например, после преобразования в BT.709 limited-range нужно передать x264 соответствующие VUI, иначе файл будет визуально зависеть от эвристик проигрывателя. Но VUI должно отражать реально выполненную операцию, а не заменять ее.
Оценка целевого битрейта для заданного размера
Когда нужен конкретный размер файла, сначала из общего бюджета вычитают аудио, контейнерный overhead и запас, а оставшийся объем переводят в средний видеобитрейт. x264 принимает --bitrate в кбит/с. Для коротких роликов служебная доля контейнера и GOP сильнее влияет на итог, поэтому точное попадание до килобайта не гарантируется. Для длинного материала двухпроходный режим обычно приближает средний битрейт к цели достаточно хорошо.
Важно считать продолжительность по реальному таймлайну, а не по числу кадров, если материал VFR. Если аудио кодируется VBR, его будущий размер тоже является оценкой. Поэтому профессиональный size constrained workflow обычно оставляет небольшой резерв и при необходимости корректирует видеобитрейт после пробного запуска.
Если одновременно заданы двухпроходный bitrate и очень жесткий VBV, rate control решает две задачи сразу: попасть в средний бюджет и не нарушить локальные пики. На тяжелом материале слишком низкий maxrate может сделать достижение желаемого среднего распределения неэффективным, поэтому параметры должны быть физически согласованы.
Как отличить проблему x264 от проблемы контейнера
Если raw .264 декодируется корректно, а после упаковки в MP4/MKV появляются неверная длительность, seek или A/V sync, первопричина может находиться уже в muxer и временных метках. x264 кодирует видео, но не управляет синхронизацией внешней аудиодорожки. Для диагностики полезно отдельно проверить элементарный AVC и затем контейнер.
Обратная ситуация тоже встречается: контейнер корректный, но x264 предупреждает о level, VBV underflow или unsupported input. Тогда проблема действительно относится к видеопотоку. Разделение стадий — decode/filter → x264 → mux — помогает быстрее понять, где возник дефект.
Не стоит использовать расширение файла как доказательство совместимости. MP4 с High 10 4:4:4 остается технически MP4, но большинство бытовых декодеров его не примут. Совместимость задается сочетанием codec/profile/level/pixel format/bit depth/VBV и контейнера.
Автоматизация нескольких файлов
При пакетном кодировании лучше не собирать огромную команду строковой конкатенацией без логирования. Для каждого входа полезно сохранять отдельный log, фактическую команду, exit code и путь результата. Если используется two-pass, stats-файл должен иметь уникальное имя на задание, иначе параллельные процессы могут перезаписать статистику друг друга.
Параллелить можно либо сам x264 на множество threads, либо несколько независимых процессов. На CPU с большим числом ядер второй подход иногда эффективнее для очереди небольших роликов, но суммарная нагрузка на память и I/O растет. Выбор зависит от разрешения, фильтров и длительности. В любом случае не следует считать 100% CPU доказательством оптимальности: bottleneck может быть в memory bandwidth или внешнем фильтре.
Для воспроизводимого рендера в ферме полезны --cpu-independent и фиксированные версии фильтров/входных библиотек. Если важна только визуальная идентичность, а не побитовое совпадение, можно оставить автооптимизации CPU. Требование определяется дальнейшей проверкой и способом кеширования результатов.
Параметры, которые чаще всего лучше не трогать
Новички часто пытаются вручную увеличить --ref, --subme, --merange, --bframes и включить --partitions all, считая каждое большее число улучшением. Но slow/veryslow уже содержат согласованные комбинации. Отдельное повышение одного параметра может дать почти нулевой выигрыш, зато увеличить время или нарушить level/совместимость.
То же относится к --qpmin/--qpmax. Слишком узкие границы ограничивают rate control и способны помешать VBV. Если нет конкретной причины фиксировать QP, значения по умолчанию лучше оставить. Похожая осторожность нужна с --ipratio, --pbratio, --qcomp, deadzone и CQM: это тонкие регуляторы внутреннего распределения, а не секретные улучшатели качества.
Правильная последовательность настройки остается прежней: preset, rate-control, tune, profile/level/VBV, затем только специальные overrides. Такой порядок проще тестировать и документировать.
Консервативная отправная точка для совместимости
Если требования приемника известны плохо, разумная стратегия — не использовать редкие профили и экстремальные overrides. Для массового SDR-доставочного файла обычно начинают с 8-bit 4:2:0, профиля High, умеренного level, стандартного preset и корректных BT.709 метаданных только тогда, когда сам материал действительно приведен к BT.709. Затем результат проверяют на целевых устройствах и уже после этого ужесточают VBV или меняют GOP.
Нельзя гарантировать совместимость одним словом high или одним номером level. Декодер одновременно видит разрешение, fps, число references, битрейт, буфер, interlace, chroma format и bit depth. Поэтому предупреждения x264 и технические требования платформы важнее универсальных рекомендуемых строк из чужих инструкций. Чем меньше необоснованных ручных параметров, тем проще найти реальную причину несовместимости.
Сравнение x264 с аналогами
x264 стоит сравнивать прежде всего с кодировщиками, которые решают ту же задачу — программное формирование сжатого видеопотока, — а не с монтажными пакетами. При этом аналоги могут использовать другой стандарт сжатия: выбор кодека меняет требования к совместимости, нагрузку на декодер и ожидаемую эффективность.
| Программа | Лучше подходит для | Главное ограничение |
|---|---|---|
| x264 | H.264/AVC с широкой совместимостью, точным CLI-контролем, CRF/2-pass/VBV и зрелыми психовизуальными настройками. | Кодирует только H.264/AVC и не занимается аудио/монтажом. |
| OpenH264 | Сценарии, где нужен открытый H.264-кодек с упором на коммуникации и интеграцию. | Меньше энкодинговых настроек и обычно ниже эффективность сжатия, чем у x264 в файловых задачах. |
| x265 | HEVC/H.265, когда приемники поддерживают HEVC и важна более высокая компрессионная эффективность при большем времени кодирования. | Совместимость старых устройств ниже, а кодирование тяжелее. |
| SVT-AV1 | AV1 на современных многоядерных CPU, потоковая доставка и большие серверные очереди. | AV1 заметно тяжелее для кодирования и требует современных декодеров. |
| rav1e | AV1 в экосистемах, где важны безопасность реализации на Rust и программная интеграция. | Ориентирован на AV1 и не заменяет H.264 при необходимости максимально широкой совместимости. |
| MainConcept AVC/H.264 Encoder | Профессиональные коммерческие рабочие процессы с готовой поддержкой вещательных профилей и интеграцией. | Коммерческая лицензия и другой набор инструментов/интерфейсов по сравнению с открытым x264. |
Если конечные устройства гарантированно поддерживают только H.264, x264 остается прямым выбором: он дает развитый rate control, строгие ограничения профиля/уровня и очень детальный CLI. Если при той же задаче допустим другой кодек и размер важнее скорости/универсальности, стоит сравнить HEVC или AV1 на конкретном материале и целевых устройствах. OpenH264 логичен для интеграционных и коммуникационных сценариев, но для тяжелого файлового энкодинга x264 обычно предлагает существенно более глубокий набор алгоритмических регулировок.
ВидеоМАСТЕР в таблицу не включен: это пользовательский конвертер более высокого уровня, тогда как x264 и перечисленные аналоги здесь сравниваются именно как кодировщики/энкодерные движки и CLI-компоненты. Они могут входить в состав других программ, но их базовая задача — сформировать видеопоток конкретного стандарта.
Что важно помнить при работе с x264
Сильная сторона x264 — не количество ручных флагов само по себе, а продуманная иерархия настроек. Preset задает устойчивую базу, CRF/bitrate определяют цель rate control, tune корректирует характер работы, profile/level и VBV обеспечивают совместимость. Большинство проблем начинается, когда пользователь берет длинную чужую команду, не понимая, какие параметры в ней уже дублируют preset или противоречат друг другу.
Самый надежный рабочий процесс строится от простого к сложному: корректно открыть вход, выбрать rate control и preset, проверить результат, затем добавить только необходимые ограничения. Логи x264 позволяют увидеть профиль, level, набор внутренних параметров и финальную статистику; их следует хранить вместе с мастер-файлом или заданием кодирования.
x264 не скрывает компромиссы. Чем глубже motion search и RD-анализ, тем больше вычислений; чем жестче VBV, тем меньше свободы распределения качества; чем шире профиль и цветность, тем ниже бытовая совместимость; чем меньше задержка, тем меньше возможностей использовать будущие кадры. Хорошая конфигурация — это не максимальные значения всех параметров, а набор ограничений, точно соответствующий источнику, времени кодирования и целевому декодеру.
