Rate Control: CBR, VBR, CRF, ABR, Capped CRF

TL;DR

Rate control – это внешний цикл, определяющий, сколько битов можно потратить на каждый кадр, сцену и весь контент в целом. В любом современном кодере реализовано пять режимов: constant bitrate (CBR), variable bitrate (VBR), constant rate factor (CRF), average bitrate (ABR) и capped CRF – они различаются тем, какое ограничение остаётся фиксированным, а какое может варьироваться. CBR фиксирует битрейт, жертвуя качеством; CRF поддерживает перцептивное качество, позволяя битрейту меняться; capped CRF сохраняет качество, но ограничивает пиковый битрейт; VBR и ABR нацелены на средний битрейт и балансируют остальное с помощью буферной модели. Выбор неподходящего режима может привести к полосатым закатам, буферизации во время трансляции или к расходам на CDN на 40% выше необходимого. В этой статье каждый режим рассматривается end-to-end – от математики до флагов FFmpeg и реальных значений, используемых Netflix, YouTube и Twitch, – и предлагается дерево решений для выбора оптимального варианта.

Почему это важно

Rate control – это та одна настройка, которая определяет, будет ли у зрителей плавная картинка, совпадёт ли счёт за CDN с таблицей и уложится ли кодирующий кластер в срок. Продакт-менеджер, который знает, что capped CRF на уровне Netflix экономит около 20% по сравнению с фиксированными ABR-лестницами, перестанет спорить с инженерами: «давайте просто опустим битрейт». Стриминг-инженер, умеющий читать логи кодера и сказать, что VBV-буфер ушёл в underflow на кадре 412, точно поймёт, почему у пользователя сорвался стрим. Основатель, выбирающий транскодинг-провайдера, увидит, что два облака на одном и том же кодеке и при одинаковом номинальном битрейте могут отдавать совершенно разные файлы – потому что их rate-control циклы принимают разные решения по распределению битов. В этой статье разбираем CBR, VBR, CRF, ABR и capped CRF, VBV/HRD буферную модель, которая держит их в рамках, практические FFmpeg-рецепты и компромиссы, о которых вы реально будете спорить в продакшене.

Что такое rate control и что им не является

Внутри кодера каждое кодирующее решение – выбор режима кодирования mode decision для блока, параметр квантования параметр квантования для этого блока, решение добавить или пропустить B-кадр – является локально оптимальным при заданном целевом значении. Rate control – это цикл, который задаёт это целевое значение. Конкретно: он отслеживает уже использованные биты, прогнозирует, сколько осталось в бюджете, и сообщает нижестоящему mode decision, какой QP (quantization parameter) использовать в следующем кадре или блоке.

Две важные путаницы. Во-первых, rate control – это не то же самое, что mode decision. Mode decision выбирает наиболее выгодный вариант J = D + λR для одного блока при фиксированном λ. Rate control, в свою очередь, определяет значение λ – обычно путём изменения QP между кадрами, что приводит к изменению λ по экспоненциальной формуле λ ≈ 0.85 × 2^((QP − 12)/3), общей для HEVC и AV1. Во-вторых, rate control – это не то же самое, что shaping полосы пропускания на сетевом уровне. Задача кодера – сформировать корректный битовый поток (compliant-битстрим), а задача CDN – его доставить. Оба уровня заинтересованы в битрейте, но по-разному.

Третий участник разговора – VBV-буфер, Video Buffering Verifier, или Hypothetical Reference Decoder (HRD) в H.264, HEVC и VVC. VBV – это гипотетический буфер на стороне декодера. Биты поступают в него с фиксированной скоростью, а кадры извлекаются с частотой кадровой развёртки. Если буфер когда-либо опустеет (underflow) – то есть декодеру понадобится следующий кадр, а данные ещё не пришли – воспроизведение остановится. Если же буфер переполнится (overflow) – то есть кодер передаст больше битов, чем может вместить буфер, – битовый поток станет несоответствующим спецификации. Каждый режим управления скоростью (rate control) учитывает определённую VBV-модель – различия между режимами заключаются в основном в том, как именно они это делают.

Нажмите, чтобы увеличить

CBR – constant bitrate, фиксированная скорость битового потока

Constant bitrate – самый старый и простой режим управления битрейтом. Он появился ещё с MPEG-1 и времён, когда видео передавалось по выделенным DVB-каналам. Кодер стремится поддерживать одинаковый битрейт от кадра к кадру, а качество при этом меняется, чтобы освободить место.

Точный алгоритм в x264 работает так: кодер отслеживает, сколько битов он уже передал по сравнению с тем, сколько должен был передать к этому моменту (frame_index × target_bitrate / frame_rate). Если он опережает бюджет – повышает QP для следующего кадра, что приводит к потере деталей и меньшему расходу битов. Если отстаёт – понижает QP и тратит больше битов. Резкие скачки QP на границах сцен могут быть слишком агрессивными; CBR-кодеры обычно ограничивают максимальный шаг изменения QP за кадр, чтобы избежать заметного мерцания.

Разберём пример. Пусть кодируем со скоростью 4000 кбит/с при 30 кадрах в секунду. За одну секунду у нас есть бюджет в 4000 × 1000 = 4 000 000 бит, то есть примерно 133 333 бита на кадр в среднем. Если за секунду кодер превысил бюджет на 500 000 бит, он увеличивает QP, пока прогнозируемый объём следующего кадра не снизится примерно на 500 000 / 30 ≈ 16 667 бит, и таким образом покрывает дефицит за окно из 30 кадров.

CBR – правильный выбор, когда выполняются одновременно два условия: downstream-канал узкий и негибкий, а потребитель не терпит буферизации. Live-вещание и live-ingest – классические примеры. Рекомендация Twitch – использовать CBR с интервалом ключевых кадров в 2 секунды, потому что ingest-инфраструктура ожидает стабильный поток, а воспроизведение не может позволить себе переход на ABR-резервный режим посреди матча. CBR также является стандартом по умолчанию в телеконференциях с низкой задержкой, поскольку бюджет на round-trip в сети ограничен, и любое падение битрейта проявляется как потеря пакетов или односторонняя передача аудио.

CBR – неправильный выбор для VOD, потому что он тратит биты впустую. Закодируйте двухчасовую драму со скоростью 5 Мбит/с в режиме CBR – и вы потратите столько же битов на чёрный экран в начале, сколько и на кульминационный бой. Диалог за кухонным столом выглядит точно так же при 1,5 Мбит/с; а боевая сцена при 5 Мбит/с всё равно будет выглядеть перегруженной. Решение – один из режимов ниже.

FFmpeg-рецепт для x264 CBR с жёстким VBV-буфером:

# CBR-like x264: цель 4 Mbps, 4 Mbps max, 4 Mbps буфер (окно 1 секунда)
ffmpeg -i in.mp4 -c:v libx264 -preset veryfast -tune zerolatency \
  -b:v 4M -maxrate 4M -minrate 4M -bufsize 4M \
  -g 60 -keyint_min 60 -sc_threshold 0 -profile:v high -pix_fmt yuv420p \
  -c:a aac -b:a 128k -ar 48000 out.mp4

Двухсекундный GOP (параметр -g 60 при 30 кадрах в секунду), отключённая коррекция переходов сцен (-sc_threshold 0) и bufsize, равный maxrate, чтобы буфер составлял «секунду битов» – именно такие настройки ожидают Twitch и большинство CDN-эндпоинтов для приёма потока.

VBR – variable bitrate, средний таргет

Переменная скорость битового потока (VBR) позволяет гибко управлять битрейтом. Кодер нацеливается на средний битрейт по всему контенту (или по длинному буферному окну) и перераспределяет биты между сценами в зависимости от их сложности: простые сцены получают меньше, сложные – больше. Благодаря этому качество изображения остаётся более стабильным, чем при использовании постоянной скорости (CBR).

Есть два варианта, с которыми вы можете столкнуться. Single-pass VBR перераспределяет битовый бюджет в реальном времени: кодер просматривает окно из 50–250 кадров вперёд, оценивает сложность каждого кадра (чем выше прогнозируемая энтропия после преобразования, тем больше битов требуется) и распределяет текущий бюджет соответственно. Это быстро и подходит для трансляции в реальном времени, но распределение ресурсов краткосрочное – кодер не знает, что через 10 секунд последует ещё более сложная сцена, и может перерасходовать битрейт на среднесложных кадрах, подойдя к действительно сложной сцене с недостаточным запасом.

Two-pass VBR это лечит. На первом проходе весь контент кодируется с placeholder-QP, и создаётся stats-файл с реальной битовой стоимостью каждого кадра. На втором проходе используется stats-файл как карта сложности: биты распределяются так, чтобы точно попасть в целевую среднюю битовую скорость – обычно с погрешностью не более 0.5% от заданного значения на 90-минутном файле. Каноничная работа – Korn et al. 2009 «A two-pass rate control algorithm for H.264/AVC HD video coding»; в ней применяется лагранжева модель rate-distortion, подогнанная под статистику по кадрам, и аналитически решается уравнение для QP, обеспечивающего попадание в бюджет.

Two-pass VBR – это основа любого VOD-пайплайна с тех пор, как появились первые DVD. Такой режим по умолчанию используется в HandBrake при выборе «Average Bitrate», в FFmpeg – через флаги -pass 1/-pass 2, а также в облачных сервисах AWS Elemental, Bitmovin, Mux и Brightcove. Главный минус двухпроходного VBR в том, что суммарное время работы CPU примерно в 2,5 раза больше, чем у однопроходного (первый проход требует меньше ресурсов, но всё равно является полноценным кодированием), и такой файл нельзя транслировать в реальном времени – целевой битрейт становится известен только после завершения кодирования.

Численный пример для наглядности распределения битов. Пусть цель двухпроходного кодирования – 4 Мбит/с × 7200 секунд = 28,8 Гб в сумме. На первом проходе анализ показывает: контент содержит 1200 секунд «лёгкого» материала (говорящие головы, статичные фоны) со средней сложностью кадра 0,4 и 6000 секунд «тяжёлого» контента (действие, движение) со сложностью 1,1. Суммарная взвешенная сложность: 1200 × 0,4 + 6000 × 1,1 = 480 + 6600 = 7080. Тогда «лёгким» секундам выделяется (480 / 7080) × 28,8 Гб = 1,95 Гб (≈ 1,63 Мбит/с), «тяжёлым» – 26,85 Гб (≈ 4,47 Мбит/с). Оба усреднённых значения соответствуют целевой скорости 4 Мбит/с, при этом биты перераспределяются туда, где они приносят наибольший прирост видимого качества.

FFmpeg-рецепт для x264 two-pass VBR:

# Pass 1: собираем статистику, пишем в ffmpeg2pass-0.log
ffmpeg -y -i in.mp4 -c:v libx264 -preset medium -b:v 4M -pass 1 \
  -an -f mp4 /dev/null

# Pass 2: применяем аллокацию, кодируем финальный файл
ffmpeg -i in.mp4 -c:v libx264 -preset medium -b:v 4M -pass 2 \
  -c:a aac -b:a 128k out.mp4

VBR с VBV-капом – иногда называемый constrained VBR – это то, что AWS Elemental, Dacast и Brightcove используют, когда оператор хочет «качество VBR с жёстким ограничением битрейта для стриминга». По структуре это аналогично capped CRF, только оптимизация направлена на битрейт, а не на коэффициент качества; подробнее об этом – ниже.

CRF – constant rate factor, фиксированный коэффициент качества

Constant rate factor – режим управления битрейтом, разработанный для x264 в середине 2000-х и впоследствии заимствованный в x265, libvpx, libaom (AV1), SVT-AV1, VVenC и эталонном кодере AOMedia. Он меняет подход: вместо фиксации битрейта и жертвования качеством CRF задаёт целевой уровень восприятия качества и позволяет битрейту варьироваться.

Точный механизм. Пользователь задаёт значение CRF между 0 и 51 (для семейства H.26x) или 0 и 63 (для AV1). Внутри кодер вычисляет базовый QP из CRF и per-frame модификатор по motion и сложности: «лёгким» кадрам – повыше QP (меньше битов, без перцептивной потери, потому что человеческий глаз снисходителен к статичному контенту), «сложным» – пониже QP (больше битов, чтобы сохранить детали). По длинному файлу средний битрейт оказывается там, куда его уведёт контент. CRF 18 для x264 на естественном видео – визуально lossless; CRF 23 – дефолт x264 и разумная стриминговая стартовая точка; CRF 28 – дефолт x265. У AV1 психовизуальная шкала другая – SVT-AV1 на CRF 30 сравним с x264 CRF 23 при битрейте на 40–50% ниже на естественном контенте.

Разберём пример, чтобы закрепить принцип работы шкалы. Закодируйте часовой 1080p30 talking-Head – типичный подкаст или вебинар – с помощью x264 при CRF 23. Получится около 1,8–2,4 Мбит/с. Теперь закодируйте тот же час быстро нарезанного спортивного контента на том же CRF 23 – например, типичную подборку моментов из Premier League – и получите 6–9 Мбит/с. Один и тот же CRF, одинаковое воспринимаемое качество, но сильно различающиеся битрейты. Вот в чём и заключается суть CRF.

CRF – правильный выбор для VOD, где пропускная способность относительно дёшева, а гарантированная ABR-лестница не требуется. Это касается личных архивов, корпоративного видео, скачиваемых обучающих материалов, мастер-файлов для последующего ретранскодинга. CRF – неподходящий вариант для ABR-стриминга сам по себе: переменный выходной битрейт нарушает предпосылки HLS- и DASH-лестниц, где плеер должен заранее знать битрейт каждого rendition. Решение – capped CRF, о чём будет рассказано в двух следующих разделах.

Замечание о том, что CRF не делает. CRF не ограничивает пиковый битрейт. Патологическая сцена может на несколько секунд превысить 25 Мбит/с и при этом остаться «compliant»-потоком с точки зрения кодека. Если вы передаёте такой файл по каналу с пропускной способностью 5 Мбит/с, воспроизведение зависнет. Поэтому любой продакшен-режим CRF для ABR использует параметры -maxrate и -bufsize – и в этот момент это уже не чистый CRF, а ограниченный (capped) CRF.

FFmpeg-рецепт для x264 CRF (plain) и каноничный референс с сайта slhck.info:

# Plain CRF: x264, цель качества 22, без cap
ffmpeg -i in.mp4 -c:v libx264 -preset slow -crf 22 \
  -c:a aac -b:a 128k out.mp4

# Plain CRF: x265, цель качества 26
ffmpeg -i in.mp4 -c:v libx265 -preset slow -crf 26 \
  -c:a aac -b:a 128k out.mp4

# Plain CRF: SVT-AV1, цель качества 30
ffmpeg -i in.mp4 -c:v libsvtav1 -preset 6 -crf 30 \
  -c:a libopus -b:a 96k out.mp4

ABR – average bitrate (и стриминговый смысл «ABR»)

Слово «ABR» в видео имеет два не связанных между собой значения, которые часто путают. Average bitrate – это режим управления скоростью битов внутри одного процесса кодирования: кодер стремится к фиксированной средней скорости битов по всему контенту. Он похож на однопроходный VBR, но с более жёстким циклом сходимости. Adaptive bitrate streaming (также «ABR») – это технология доставки, при которой плеер динамически переключается между несколькими заранее закодированными версиями видео. Общим у них остаётся только аббревиатура.

В контексте управления битрейтом ABR – это режим x264 -b:v 4M без флагов -pass. Он использует тот же трекер сложности, что и однопроходный VBR, но с более агрессивной конвергенцией – эвристика настроена на «попадание в 4 Мбит/с ±2%, не тратя ресурсы на тонкости». ABR – это то, к чему прибегают, когда нужна предсказуемость битрейта без затрат второго прохода, а небольшой разброс качества, который сгладил бы VBR, не критичен.

В контексте стриминга ABR означает, что CDN предоставляет несколько предварительно закодированных файлов с разными битрейтами, а плеер выбирает подходящий. Каждый файл в «лестнице» закодирован с использованием определённого режима управления скоростью – исторически это был двухпроходный VBR, сегодня всё чаще применяется ограниченный CRF. Сама «лестница» – это набор, который ABR-протоколы, такие как HLS или DASH, передают плееру (см. adaptive bitrate streaming).

Знаковая статья Netflix 2015 года о «per-title encoding» изменила подход к построению битрейтовых лестниц. Вместо кодирования каждого контента по одной и той же фиксированной лестнице (235, 560, 1050, 1750, 2350, 3000, 4300, 5800 kbps для 1080p – так называемая «Netflix ladder») компания стала проводить анализ каждого произведения отдельно: запускала analysis-pass, строила выпуклую оболочку (convex hull) точек (разрешение, битрейт, качество) по метрике VMAF и выбирала ступени, охватывающие эту оболочку. По каталогу экономия трафика составила в среднем около 20% при неизменном качестве (Aaron, Li, Manohara et al. 2015 – Netflix Tech Blog «Per-Title Encode Optimization»). Эта техника позволила сократить общий объём данных до 40% по сравнению с фиксированными лестницами.

«Dynamic Optimizer» 2018 года пошёл дальше: кодировать каждый кадр (несколько секунд стабильной камеры и освещения) независимо, строить для него выпуклую оболочку (convex hull) и сшивать оптимальные кадры. Netflix сообщил о 30%+ экономии битрейта по сравнению с per-title при неизменном VMAF. Современные VOD-пайплайны Netflix работают примерно в режиме per-shot оптимизации с ограниченным CRF в качестве внутреннего режима управления битрейтом.

Если у вас нет масштаба Netflix, простая победа – это всё равно per-title. Mux, Bitmovin и Cloudinary предлагают «автоматическое per-title кодирование» как сервис, а у AWS Elemental MediaConvert есть встроенный режим «Automated ABR».

Capped CRF – таргет по качеству плюс жёсткий потолок

Capped CRF – это режим, который вам действительно нужен для большинства задач стриминга в 2026 году. Внутри работает CRF-цикл: перцептивная цель по качеству, переменный битрейт на выходе, но с ограничением максимального битрейта через VBV-буфер. Контракт такой: «дай мне качество CRF 23, но ни в коем случае не превышай 6 Мбит/с при односекундном буфере на 6 Мбит».

Поведение. На лёгком контенте (talking heads, low-motion VOD) доминирует CRF: кодер работает в диапазоне 1–3 Mbps, и лимит не срабатывает. На тяжёлом контенте (спорт, экшн, резкие смены сцен) лимит берёт верх: кодер не может достичь целевого значения CRF, не превысив лимит, поэтому повышает QP ровно до тех пор, пока не упрётся в лимит. Чистый эффект – «столько качества, сколько могу себе позволить, но без буферизации».

По сравнению с plain CBR на том же cap, capped CRF экономит 20–40% пропускной способности на типичном контенте, поскольку лёгкие сцены используют меньше битрейта. По сравнению с plain CRF, capped CRF обеспечивает предсказуемость битрейта, необходимую для ABR. По сравнению с двухпроходным VBR при том же среднем значении, capped CRF использует один проход (дешевле, быстрее, подходит для live-трансляций) и задаёт жёсткий лимит вместо мягкого среднего.

Capped CRF – это подход, который с 2020 года рекомендует Jan Ozer из Streaming Learning Center. Его используют по умолчанию в новых VOD-пайплайнах такие компании, как Bitmovin, Mux, Brightcove и Visionular. Аппаратно-ускоренные VPU-кодеры NETINT реализуют capped CRF как бесплатную версию «content-aware encoding» без отдельного анализа (analysis pass). Режим «Automated ABR» в AWS Elemental также построен на принципе capped CRF.

Численный пример. Закодируйте часовой видеофайл в формате x265 с параметрами CRF 24, ограничением скорости до 5 Мбит/с и буфером размером 5 Мбит. В выходном файле будут присутствовать три режима:

• Холодное открытие и финальные титры (мало движения, почти чёрные кадры). CRF-таргет – 0,6 Мбит/с; лимит не используется.
• Основные диалоги и драматические сцены (умеренное движение, крупные планы, средние планы). CRF – 2,5–3,5 Мбит/с; лимит не используется.
• Action-эпизоды и быстрые склейки. CRF требует 7–9 Мбит/с, но лимит ограничивает кодирование 5 Мбит/с, из-за чего QP повышается на 2–4 единицы в этих сценах.

Среднее значение по файлу – около 2,8 Мбит/с. Тот же контент при фиксированной скорости 5 Мбит/с в режиме CBR дал бы среднюю скорость 5 Мбит/с, но с ухудшением качества в сценах действия (поскольку CBR обязан равномерно распределять фиксированный объём битрейта) и неоправданно завышенной нагрузкой на сцены с диалогами.

FFmpeg-рецепты для capped CRF – те самые, что вы будете копипастить:

# Capped CRF x264: цель 22, cap 5 Mbps, буфер 10 Mbit (2-секундный)
ffmpeg -i in.mp4 -c:v libx264 -preset medium -crf 22 \
  -maxrate 5M -bufsize 10M \
  -c:a aac -b:a 128k out_x264.mp4

# Capped CRF x265: цель 26, cap 5 Mbps, буфер 10 Mbit
ffmpeg -i in.mp4 -c:v libx265 -preset medium -crf 26 \
  -x265-params "vbv-maxrate=5000:vbv-bufsize=10000" \
  -c:a aac -b:a 128k out_x265.mp4

# Capped CRF SVT-AV1: цель 30, cap 5 Mbps, буфер 10 Mbit
ffmpeg -i in.mp4 -c:v libsvtav1 -preset 6 -crf 30 \
  -maxrate 5M -bufsize 10M \
  -c:a libopus -b:a 96k out_av1.mp4

Обратите внимание на соотношение буфер/битрейт. 2× буфер (10 Мбит при лимите 5 Мбит/с, окно 2 секунды) – комфортный вариант по умолчанию для VOD. 1× буфер (5 Мбит при лимите 5 Мбит/с, окно 1 секунда) – оптимальный выбор для трансляции с низкой задержкой. 0.5× буфер (2,5 Мбит при лимите 5 Мбит/с) – правильный выбор для ультра-низколатентных конференций, где любая буферизация вызывает задержку в аудио.

Нажмите, чтобы увеличить

Где здесь место lambda – стыковка управления скоростью и выбора режима

Rate control и mode decision используют одну и ту же переменную – λ. Цикл mode decision минимизирует величину J = D + λR в каждом блоке, а цикл rate control подбирает значение λ, выбирая QP. Внутри HEVC эта связь реализуется

λ_mode = α · 2^((QP − 12) / 3)

С α около 0,85 для B-кадров. Тот же экспоненциальный закон, но с несколько иными константами, действует в любом современном кодере. «Rate control поднимает QP на 6» эквивалентно «λ удваивается», что в свою очередь означает: «mode decision готов тратить вдвое меньше битрейта на единицу искажения».

Почему это важно. Когда VBV сообщает: «вы превысили бюджет на 200 kbit», цикл управления битрейтом переводит это в команду: «повысить QP на N в следующих M кадрах». В этих кадрах алгоритм выбора режима (mode decision) начинает работать с более высоким λ, и его решения на уровне блоков смещаются в сторону более простых – меньше transform-коэффициентов, меньшие partition, больше skip-блоков. Изображение становится грубее, чтобы освободить битовый бюджет. Когда бюджет комфортный, λ снижается, mode decision выбирает более сложные режимы, и изображение становится точнее.

Два практических следствия. Первое: тюнинг-флаги вроде --psy-rd, --psy-rdoq, --aq-mode – это небольшие корректировки эффективного λ в процессе выбора режимов, накладываемые поверх решений, принимаемых контроллером битрейта. С их помощью реализуются настройки вроде «оптимизация под VMAF» или «оптимизация под SSIM». Второе: capped CRF работает именно потому, что при срабатывании лимита повышение QP на несколько единиц – это как раз правильная корректировка: она равномерно увеличивает λ по всему кадру, и выбор режимов становится дешевле повсеместно, не концентрируясь на «голодных» областях.

Восемь продакшен-сценариев – и какой режим выигрывает в каждом

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

Как настроены rate control в реальных сервисах в 2026

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

Netflix. Пересъёмка кодирования с ограниченным CRF внутри каждого кадра. В процессе используются два эталонных кодера: первый – проход предварительной аналитики, определяющий границы сцен и целевые значения CRF для каждой сцены, второй – финальный проход, формирующий итоговый битовый поток. Оптимизация на уровне сцены (shot-level convex hull) подбирает комбинацию (разрешение, CRF), максимизирующую VMAF на бит. Внутреннее название технологии – Dynamic Optimizer. Отчётная экономия: около 30% битрейта при неизменном VMAF по сравнению с per-title (Netflix Tech Blog, несколько постов 2018–2024).

YouTube. Per-Title Encoding с ограниченным CRF для VOD; CBR – для прямых трансляций. Рекомендация YouTube для стримеров, опубликованная в 2024 году, включает заданные диапазоны битрейта и ключевые кадры каждые 2 секунды для live. Что касается VOD, YouTube перекодирует загруженные видео через внутренний кодек-пайплайн, в котором используется per-title CRF-анализ.

Twitch. CBR end-to-end на уровне ingest. Опубликованное руководство для стримеров однозначно требует CBR с интервалом ключевых кадров в 2 секунды. Transcoded-выход для ABR-доставки также использует CBR на каждом уровне – Twitch оптимизирует систему под низкую задержку, а не под эффективность использования полосы пропускания.

Disney+ / Hulu / HBO Max. Перетайлинг с ограниченным CRF на облачных транскодерах (AWS Elemental MediaConvert, Bitmovin или собственные решения). Большинство платформ используют x265 или AV1 с preset 6 / --rd 4, CRF 22–26, с ограничением по номинальному битрейту рендера.

Zoom / Microsoft Teams. CBR поверх WebRTC с очень жёстким VBV (~250–500 мс). Обе платформы используют scalable video coding (SVC) на базе H.264 SVC или AV1, при этом темпоральные и пространственные слои SVC добавляют дополнительное измерение управления битрейтом, подробно рассмотренное в WebRTC-deep-dive.

Surveillance NVR (Avigilon, Milestone, Hikvision и т. п.) – Capped CRF или constrained VBR с очень низким лимитом, настроенный на долговечность диска, а не на визуальное качество. На статичных сценах нагрузка держится на уровне 100–300 кбит/с; при движении пиковая нагрузка достигает установленного лимита.

VBV – буферное ограничение, на котором всё держится

Каждый режим управления скоростью, учитывающий буфер, реализует одну и ту же модель: биты поступают в условный буфер со скоростью канала, кадры извлекаются с частотой кадровой развёртки, а уровень заполнения буфера должен оставаться в пределах его ёмкости в каждый момент времени. В терминологии спецификации битового потока это Coded Picture Buffer (CPB) в H.264/HEVC – то же самое, что VBV в литературе по кодированию.

Два важных параметра:

• VBV-maxrate. Скорость, с которой буфер заполняется битами. В CBR-режиме это целевой битрейт. В capped CRF или constrained VBR – это максимальный битрейт, который может достигать выходной поток.
• VBV-bufsize. Объём буфера. Примерно – сколько битов можно накопить в лёгких сценах, чтобы использовать их для обработки следующей сложной. Чем больше буфер, тем больше возможностей для VBR-аллокации, но при этом возрастает задержка end-to-end (декодеру нужно дождаться заполнения буфера перед началом воспроизведения). Буфер на 2 секунды – стандарт для стриминга; 0,5 секунды – для видеоконференций; 8 секунд – для вещания.

HEVC HRD добавляет к H.264 два улучшения. Первое – sub-picture-level HRD operation: теперь буфер можно отслеживать на уровне сегментов кадра, а не только целого кадра, что повышает точность при ультра-низкой задержке. Второе – альтернативные наборы начальных параметров буферизации в точках случайного доступа, что позволяет декодеру корректно пересинхронизировать буфер на каждом IDR-кадре без переполнения. Оба подхода подробно описаны в работе Improved Hypothetical Reference Decoder for HEVC (Hannuksela et al. 2013).

Распространённая инженерная ошибка – установить bufsize == maxrate. Это сводит VBV к скользящему окну продолжительностью в одну секунду. Качество заметно падает, поскольку кодер не может накапливать биты между сценами. Исправление: bufsize = 2 × maxrate для VOD или 1 × maxrate для live-трансляций, если нет особых причин ограничивать задержку.

Нажмите, чтобы увеличить

Частые ошибки – пять, которые мы видим в реальных аудитах

1. Несоответствие размера буфера. Условие bufsize == maxrate приводит к коллапсу VBV. Фиксация: 2× для VOD, 1× для live. Это проявляется как банинг или блокинг на склейках сцен, которые сами по себе не являются сложными.

2. CRF для ABR-лестницы без cap. Резкий скачок до 25 Mbps на ступени 4 Mbps сбивает оценку пропускной способности плеера. Исправление: использовать capped CRF с maxrate, равным номинальному значению ступени.

3. Two-pass VBR для live-стримов. Two-pass для live-ингеста невозможен. Фикс: capped CRF или CBR для live; two-pass – только для VOD.

4. Сравнение пресетов по iso-CRF, а не по iso-битрейту. Более быстрый пресет при том же CRF даёт больший файл и худшее качество – кодер делает менее точные mode-decision и тратит больше битов на компенсацию. Правильное сравнение – по iso-битрейту или iso-VMAF. Это самая распространённая ошибка в блогах, где оценивают кодеры.

5. Одновременное задание -b:v и -crf. Они конфликтуют. Побеждает -crf, а -b:v становится игнорируемым параметром – кодер использует его как ориентир, но фактически не учитывает. Кодер обычно выводит предупреждение, которое, как правило, никто не замечает. Решение: используйте либо один параметр, либо другой, но не оба одновременно.

Где здесь Фора Софт

Мы проектируем и эксплуатируем видеопайплайны для стриминга, OTT/Internet TV, видеоконференций, телемедицины, e-learning и видеонаблюдения. В каждой из этих областей оптимальная стратегия управления битрейтом (rate control) своя. Телемедицинская консультация требует CBR с VBV-буфером менее секунды, чтобы аудио оставалось синхронным с речью врача. Для OTT VOD-лестницы эффективны per-title или per-shot capped CRF – они позволяют сэкономить 20–30% на расходах CDN по сравнению с фиксированной лестницей. Рекордеру для видеонаблюдения нужен агрессивный capped CRF с низким порогом, чтобы уложиться в бюджет хранения на 30 дней при типичном объёме хранилища. Мы настраиваем каждый пайплайн под ключевую метрику своей вертикали – VMAF для VOD, MOS для конференций, стоимость одного дня хранения для видеонаблюдения – и собираем логи кодировщика так, чтобы поведение rate control было отслеживаемо в продакшене.

Что дальше – content-aware и нейронный rate control

Следующая граница в управлении скоростью – перенос принятия решений выше по цепочке обработки. В литературе 2024–2025 годов выделяются два направления:

Content-aware rate control без отдельного analysis-pass. VPU-ускоренные кодеры NETINT реализуют быстрый классификатор сложности, встроенный в цикл кодирования, который по кадрам подстраивает эффективный CRF-таргет. Классификатор настолько компактен, что способен работать в реальном времени на 4K. Результат – эффективность использования полосы пропускания на уровне per-title без необходимости отдельного анализа; маркетинговая формулировка NETINT – «бесплатное CAE».

Нейронные политики rate control. Статья ECCV 2024 «Learned Rate Control for Frame-Level Adaptive Neural Video Compression» описывает обучение нейросетевой политики, которая на основе состояния кодера и целевого битрейта предсказывает значение QP, обеспечивающее наилучший баланс между битрейтом и искажением на уровне кадра. Отчётный прирост – 14,8 % по BD-рейту по сравнению с традиционным пайплайном rate control и RDO на уровне кадра. Более компактные block-уровневые версии этой идеи реализованы в исследовательских кодовых базах.

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

Ключевые выводы

• Управление скоростью (rate control) выбирает QP (а значит, и λ), который будет использоваться циклом принятия решений по режимам; это внешний цикл по отношению к блочному кодированию.
• CBR фиксирует битрейт, CRF – перцептивное качество, VBR усредняет по содержанию, ABR (в контексте управления скоростью) динамически нацеливается на среднее значение, capped CRF сохраняет качество, но ограничивает пиковые значения.
• Любой режим работы учитывает буфер VBV/HRD; bufsize = 2 × maxrate – разумный стандартный выбор для VOD.
• Capped CRF – оптимальный выбор для большинства современных сценариев стриминга и видеонаблюдения: цель – качество с жёстким ограничением сверху.
• Netflix экономит около 30% битрейта при использовании capped CRF на уровне кадра; capped CRF на уровне видео – около 20%; оба подхода превосходят фиксированные битрейт-лестницы.
• Сравнения пресетов по изокачеству (iso-CRF) вводят в заблуждение; всегда сравнивайте кодеры при одинаковом битрейте (iso-bitrate) или одинаковом качестве (iso-quality).

Что читать дальше

• Квантование: где теряется качество – QP, который регулирует rate control.
• Mode Decision и Rate-Distortion Optimization – внутренний цикл, за которым следит rate control.
• Adaptive bitrate streaming – как rate-controlled версии превращаются в ABR-лестницу.