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 – это не то же самое, что bandwidth 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 – самый старый и простой режим rate control. Идёт с MPEG-1 и времён, когда видео ехало по выделенным DVB-транспортам. Кодер таргетирует один и тот же битрейт кадр за кадром. Качество двигается, чтобы освободить место.

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

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

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

CBR – неправильный ответ для VOD, потому что транжирит биты. Закодируйте двухчасовую драму на 5 Mbps CBR – и вы потратите столько же битов на чёрный экран в холодном открытии, сколько на кульминационный бой. Talking head за кухонным столом выглядит ровно так же, как выглядел бы на 1.5 Mbps; боевая сцена голодает на 5 Mbps. Фикс – один из режимов ниже.

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 fps), отключённая scene-cut коррекция (-sc_threshold 0), bufsize равный maxrate, чтобы буфер был «секунда битов», – ровно то, что ждёт Twitch и большинство CDN ingest endpoints.

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

Variable bitrate отпускает битрейт. Кодер таргетирует средний битрейт по всему контенту (или по длинному буферному окну) и перераспределяет биты между сценами по сложности. Простые сцены тратят меньше, сложные – больше. Качество держится ближе к константе, чем при CBR.

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

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

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

Численный пример, чтобы конкретизировать аллокацию. Пусть two-pass таргет – 4 Mbps × 7200 секунд = 28.8 Gb всего. Первый проход сообщает: контент содержит 1200 секунд «лёгкого» контента (говорящие головы, статичные фоны) со средней per-frame complexity 0.4 и 6000 секунд «тяжёлого» контента (action, motion) с фактором 1.1. Суммарная взвешенная сложность = 1200 × 0.4 + 6000 × 1.1 = 480 + 6600 = 7080. Тогда лёгкие секунды получают (480 / 7080) × 28.8 Gb = 1.95 Gb (≈ 1.63 Mbps), тяжёлые – 26.85 Gb (≈ 4.47 Mbps). Оба усреднения дают целевые 4 Mbps, при этом биты переезжают туда, где они покупают больше видимого качества.

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, только цель оптимизации – битрейт, а не quality-factor; вернёмся к этому ниже.

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

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

Точный механизм. Пользователь задаёт значение 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 Mbps. Закодируйте тот же час быстро-нарезанного спортивного контента на том же CRF 23 – типичная нарезка Premier League – получится 6–9 Mbps. Один CRF, одно воспринимаемое качество, очень разные битрейты. В этом и весь смысл CRF.

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

Замечание о том, что CRF не делает. CRF не ограничивает пиковый битрейт. Патологическая сцена может пробить 25 Mbps на несколько секунд и всё равно остаться «compliant»-CRF-потоком с точки зрения кодека. Если вы отдаёте этот файл по 5 Mbps мобильному каналу, воспроизведение встанет. Поэтому любой продакшен-CRF для ABR крутится с -maxrate и -bufsize – и в этот момент это уже не plain 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 – режим rate control внутри одного кодирования: кодер таргетирует фиксированное среднее по контенту, похоже на single-pass VBR, но с более тугим циклом конвергенции. Adaptive bitrate streaming (тоже «ABR») – техника доставки, где плеер на лету переключается между несколькими pre-encoded rendition. Общая у них только аббревиатура.

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

В стриминговом смысле ABR – это допущение, что CDN отдаёт несколько pre-encoded файлов на разных битрейтах, а плеер выбирает один. Каждый файл внутри лестницы сам по себе закодирован в каком-то режиме rate control – исторически two-pass VBR, всё чаще capped CRF. Лестница – это то, что ABR-протоколы вроде HLS или DASH манифестируют плееру (см. adaptive bitrate streaming).

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

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

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

Capped CRF – quality-таргет плюс жёсткий потолок

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

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

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

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

Численный пример. Закодируйте часовое смешанное видео на x265 CRF 24 с cap 5 Mbps и 5-Mbit буфером. В выходном файле появятся три режима:

• Холодное открытие и финальные титры (low motion, near-black frames). CRF-таргет приземляется на 0.6 Mbps; cap нерелевантен.
• Основные диалоги и драматические сцены (moderate motion, talking heads, mid-shots). CRF на 2.5–3.5 Mbps; cap нерелевантен.
• Action-эпизоды и быстрые склейки. CRF хотел бы 7–9 Mbps; cap зажимает кодирование до 5 Mbps, и QP поднимается на 2–4 в этих сценах.

Среднее по файлу около 2.8 Mbps. Тот же контент на фиксированном 5 Mbps CBR дал бы среднее 5 Mbps с худшим качеством в action-сценах (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 Mbit при cap 5 Mbps, 2-секундное окно) – комфортный дефолт для VOD. 1× буфер (5 Mbit при cap 5 Mbps, 1-секундное окно) – правильный ответ для low-latency live. 0.5× буфер (2.5 Mbit при cap 5 Mbps) – правильный ответ для ультра-low-latency конференций, где любая буферизация лезет в аудио-лаг.

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

Где сюда вписывается lambda – стык rate control и mode decision

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 согласен тратить вдвое меньше rate на единицу искажения».

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

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

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

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

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

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

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

YouTube. Per-title encoding с capped CRF для VOD; CBR для live. Опубликованная в 2024 году рекомендация YouTube для стримеров – заданные диапазоны битрейта и 2-секундные keyframes для live. На VOD-стороне YouTube перекодирует загрузки через внутренний кодек-пайплайн, включающий per-title CRF-анализ.

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

Disney+ / Hulu / HBO Max. Per-title capped CRF на облачных транскодерах (AWS Elemental MediaConvert, Bitmovin или in-house). Большинство выкатывает x265 или AV1 на preset 6 / --rd 4, CRF 22–26, cap на номинальном битрейте rendition.

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

Surveillance NVR (Avigilon, Milestone, Hikvision и т.п.). Capped CRF или constrained VBR с очень низким cap, настроенный на disk endurance, а не визуальное качество. Статичные сцены висят на 100–300 kbps; motion-события пиково упираются в cap.

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

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

Два значимых параметра:

• VBV-maxrate. Канальная скорость, с которой буфер заполняется. В CBR-кодировании это целевой битрейт. В capped CRF или constrained VBR – максимальный битрейт, который может выдерживать выходной поток.
• VBV-bufsize. Ёмкость буфера. Грубо – сколько битов можно «накопить» в лёгких сценах, чтобы потратить на следующую сложную. Больше буфер – больше места для VBR-style аллокации, но больше end-to-end латентность по проводу (декодер должен заполнить буфер до начала воспроизведения). 2-секундный буфер – стриминговый стандарт; 0.5-секундный – конференционный; 8-секундный – broadcast.

HEVC HRD добавляет к H.264 два улучшения. Первое – sub-picture-level HRD operation: буфер можно отслеживать на гранулярности picture-segment, не только picture, что делает ультра-low-latency более точной. Второе – alternate sets of initial buffering parameters at random-access points, чтобы декодер мог чисто пересинхронизировать буфер на каждом IDR-кадре без overflow. Оба разобраны в Improved Hypothetical Reference Decoder for HEVC (Hannuksela et al. 2013).

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

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

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

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-ingest невозможен. Фикс: capped CRF или CBR для live; two-pass держите для VOD.

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

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

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

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

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

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

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

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

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

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

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

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

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