Содержание статьи +
TL;DR
Битрейтная лестница (bitrate ladder) – это набор пар «разрешение–битрейт», который ваш сервис предлагает зрителям, и старый способ её построить состоял в копировании фиксированного списка из спецификации Apple HLS. Per-title encoding анализирует содержимое каждого видео и строит индивидуальную лестницу под конкретное видео, что обычно сокращает расходы на хранение и трафик на 20–80% при той же визуальной чёткости. Per-scene encoding (известное также как shot-based или content-adaptive encoding) идёт ещё дальше и варьирует битрейт внутри одного видео – от сцены к сцене, чтобы спокойный диалог не оплачивал трафик за соседнюю сцену с погоней. Эта статья проходит через всю математику, алгоритмы, реальные данные по экономии от Netflix, Bitmovin и Mux, а также объясняет, как выбрать подход под ваш сервис.
Зачем это нужно
Если вы стримите видео зрителям, выбор битрейтной лестницы одновременно определяет три вещи: ежемесячный счёт от CDN, чистоту картинки на каждой скорости соединения и скорость восстановления плеера после провала сети. Фиксированная лестница, взятая из спецификации 2017 года, перерасходует битрейт на простом контенте (вебинары) и недодаёт битов сложному (спорт) – оба исхода плохи. Продакт-менеджерам и основателям важно понимать этот компромисс, потому что экономия достаточно велика (10–80% на трафике в зависимости от каталога), чтобы покрыть квартал работы над новой фичей. Инженерам это нужно потому, что алгоритмы внутри per-title encoding опираются на математику выпуклых оболочек, машинное обучение и метрики качества вроде VMAF – то, чего старая модель фиксированной лестницы не требовала.
Что Такое Битрейтная Лестница
Прежде чем перейти к «per-title», убедимся, что под «лестницей» мы понимаем одно и то же. В adaptive streaming – технологии, которая позволяет вашему телефону переключиться с HD на SD, когда поезд заходит в тоннель – сервис одновременно отдаёт одно и то же видео в нескольких уровнях качества. Каждый уровень имеет разрешение (например, 1920×1080 пикселей) и средний битрейт (например, 5 мегабит в секунду, записывается 5 Mbps). Весь набор пар (разрешение, битрейт) и есть битрейтная лестница. Плеер ходит вверх-вниз по этой лестнице во время воспроизведения, выбирая самый высокий уровень, который текущая пропускная способность тянет. Думайте о лестнице как о размерах кофе в кофейне: один и тот же напиток, разные объёмы, выбор за гостем.
Спецификация Apple HLS Authoring Specification, которую большинство инженеров до сих пор берут за стартовую точку, рекомендует примерно девять–двенадцать ступеней для H.264 – значения вроде 145 kbps при 416×234, 1 Mbps при 768×432, 4.5 Mbps при 1280×720 и 7.8 Mbps при 1920×1080. Сама Apple оговаривает, что это «начальные цели» и что битрейт стоит подбирать под конкретный контент, но на практике многие пайплайны отгружают эти числа дословно. Это и есть фиксированная лестница. Она не знает, мультфильм у вас на входе, финал Лиги чемпионов или статичная презентация – и тратит одинаковое количество бит на все три случая.
Идея Per-Title Encoding
Per-title encoding выбрасывает фиксированную лестницу и строит новую под каждое поступившее видео. Высокоуровневый рецепт, опубликованный Netflix в 2015 году в инженерном блоге (и запустивший всю индустрию), состоит из трёх шагов. Сначала кодируем видео в нескольких разрешениях и при нескольких уровнях качества – получаем облако точек (разрешение, битрейт, качество). Затем проводим кривую, соединяющую лучшие из этих точек, – максимально достижимое качество при заданном битрейте. Эта кривая называется выпуклой оболочкой (convex hull) – математическая граница «лучше уже не получится на этом энкодере и этом контенте». Наконец, расставляем ступени лестницы вдоль этой кривой на тех битрейтах, которые реально использует ваша аудитория.
Метрика качества на втором шаге редко бывает «сырым» PSNR (peak signal-to-noise ratio), потому что PSNR плохо коррелирует с тем, что видит человек. Большинство современных пайплайнов используют Video Multi-method Assessment Fusion (VMAF) – метрику, которую Netflix выложил в open source в 2016 году. VMAF оценивает видео по перцептивной шкале 0–100, где 93 – broadcast-grade, а 95 – практически не отличается от оригинала. (Подробнее в нашей статье про метрики качества.)
Зачем нужна выпуклая оболочка? Потому что для конкретного видео 1080p при 1.5 Mbps может выглядеть хуже, чем 720p при тех же 1.5 Mbps. Лишние пиксели 1080p требуют битов, которые энкодер вынужден отнять у тех зон, которые человек реально замечает – границ и лиц. Выпуклая оболочка говорит, какое разрешение выигрывает при каждом битрейте. Для тихой анимации 1080p может начать побеждать с 1.2 Mbps; для быстрого хоккейного матча – только с 5 Mbps.
Математика Экономии Битрейта
Возьмём типичный полнометражный фильм длительностью 90 минут с фиксированной ступенью 1080p при 6 Mbps. Полный объём трафика для одного зрителя, досмотревшего до конца:
объём = битрейт × время
= 6 Mbps × 5,400 секунд
= 32,400 мегабит
= 4,050 мегабайт
≈ 4.05 GBТеперь предположим, что per-title анализ обнаружил: именно этот фильм – допустим, диалоговая драма – добивает того же VMAF 95 уже на 3.2 Mbps. Новый объём:
объём_новый = 3.2 Mbps × 5,400 с
= 17,280 Mb
= 2,160 MB
≈ 2.16 GBЭто 47% сокращение исходящего трафика для этого фильма. Если CDN берёт 1 цент за гигабайт, а фильм набирает 5 миллионов просмотров в год, экономия:
экономия = (4.05 − 2.16) GB × 5,000,000 просмотров × $0.01/GB
= $94,500 в год на одно видеоЭто выражение – «умножить дельту на просмотр на количество просмотров на удельную цену» – и есть весь бизнес-кейс per-title encoding в одной строке. Оно же объясняет, почему экономия концентрируется в самых просматриваемых видео: оптимизация даёт одинаковый процент на каждом, но долларовая сумма масштабируется по просмотрам.
Где Per-Title Не Срабатывает – и Где Начинается Per-Scene
Per-title строит одну лестницу на всё видео – значит, каждая часть видео платит одинаковый битрейт в секунду. Это работает там, где сложность контента более-менее равномерна – выпуск новостей, вебинар, ситком со статичной камерой. И гораздо хуже работает там, где сложность скачет: триллер, который чередует тёмные диалоги в интерьере и сцены погони, или спортивная трансляция, которая режет между общим планом поля и крупным планом травы.
В триллере диалоговая сцена выглядит идеально на 1.5 Mbps – движения почти нет, камера закреплена. Сцена погони требует 8 Mbps, чтобы избежать блочности на быстрых панорамах и крупных кадрах. Per-title лестница выбирает один битрейт, скажем 4 Mbps, который усредняет разницу – диалог перерасходует 2.5 Mbps, а погоня недодаёт 4 Mbps и показывает артефакты. Глаз зрителя цепляется именно за артефакты, а не за экономию на диалоге.
Per-scene encoding (также shot-based encoding или content-adaptive encoding) решает это, разделяя видео на shots (кадры в смысле «кусок съёмки между склейками») и подсчитывая отдельную лестницу для каждого shot. Один shot – это непрерывная съёмка без склейки; в большинстве профессионального контента средний shot длится около 4 секунд, так что 60-минутная драма содержит около 900 shots. Netflix Dynamic Optimizer, развёрнутый в продакшене в 2018 году, кодирует каждый из этих shots на нескольких точках качества, прогоняет лагранжеву оптимизацию по всему фильму, чтобы выбрать per-shot качество, минимизирующее общий битрейт при заданном среднем VMAF, и склеивает обратно. Netflix отрапортовал дополнительную экономию 17.1% поверх per-title: короткие сцены опускаются до меньших разрешений, а напряжённые сцены забирают освободившиеся биты себе.
Типичная Ошибка: Резать Только По Границам GOP
Подвох, на который попадает каждый инженер при первой попытке per-scene encoding: shots обязаны начинаться на границах GOP (group of pictures), чтобы плеер мог чисто переключать ступени лестницы. (Подробнее в статье про GOP-структуру.) Если ваш детектор сцен находит границу shot посередине closed GOP, у вас два плохих варианта: разрезать GOP и принять глитч декодирования или передвинуть границу shot на следующий keyframe и потерять часть оптимизации. Решение, применяемое Netflix, Bitmovin и Mux, – принудительно ставить keyframe на каждой найденной границе shot в проходе анализа. Это делает каждый shot чуть хуже сжимаемым (каждый shot теперь начинается с дорогого I-кадра), но потеря от лишних keyframes гораздо меньше, чем выигрыш от per-shot адаптации.
Как Алгоритмы Работают На Практике
В 2026 году в продакшене встречаются три варианта реализации, отсортированные по сложности:
Brute-Force Test Encodes (оригинальный метод Netflix)
Для каждого видео прогоняем кодирование во всех комбинациях (разрешение, битрейт): например, пять разрешений × восемь битрейтов = сорок тестовых кодирований, и измеряем VMAF на каждом. Строим выпуклую оболочку по этим сорока точкам, выбираем ступени, попадающие в нужный диапазон VMAF, остальное выбрасываем. Это самый точный метод, потому что напрямую измеряет, что произведёт энкодер. Это же и самый дорогой: сорок тестовых кодирований – на порядок больше вычислений, чем одно финальное кодирование, так что один проход анализа может стоить дороже, чем весь фиксированный пайплайн. Netflix может себе это позволить, потому что итоговые биты раздаются примерно 270 миллионам подписчиков; амортизация на просмотр делает стоимость незаметной.
Lookahead-Плюс-Один-Энкод (Bitmovin / классический CAE)
Прогоняем быстрый первичный анализ файла – например, один проход в пятой скорости на исходном разрешении или CRF-зонд, – собираем статистику (motion energy, spatial complexity, шум) и скармливаем её модели, которая предсказывает выпуклую оболочку, не прогоняя все комбинации. Модель может быть ручной (ранние CAE-системы) или обученной на бенчмарковом датасете (современные системы). На выходе – лестница той же формы, что и у brute force, но за стоимость примерно одного лишнего кодирования. Bitmovin в публичном datasheet рапортует до 87% экономии на верхних рендициях и более 22% улучшения top-line VMAF при том же битрейте.
Neural-Network Inference (Mux Instant Per-Title, ML-CAE)
Прогоняем исходник через свёрточную нейросеть, на выходе которой – сразу готовая лестница: ни тестовых кодирований, ни зондового прохода, только инференс на сырых кадрах. Тренировочные данные – brute-force лестницы для десятков тысяч клипов; сеть учится отображению «как выглядит контент → какой должна быть лестница». Время инференса – миллисекунды, что и делает этот подход реализуемым для live-стримов, где бюджета на зонд просто нет. Mux публично описывает этот подход как основу своего instant per-title пайплайна. Точность чуть ниже brute force на out-of-distribution контенте, но разница в скорости – шесть порядков.
| Метод | Стоимость анализа | Подходит для live | Типичная экономия vs фиксированной | Где блистает |
|---|---|---|---|---|
| Brute-force test encodes | 10–40× одного кодирования | Нет | 20–50% | Премиальные VOD-каталоги с большим числом просмотров |
| Lookahead + CAE-модель | ~1.2–1.5× одного кодирования | На границе (chunked live) | 20–40% | Средние VOD-библиотеки; live с задержкой в несколько секунд |
| Neural-network инференс | Миллисекунды | Да | 15–35% | Live; UGC; очень большие библиотеки |
Подробнее о том, какие энкодеры стоят ниже по пайплайну после любой из этих методик, см. статью про rate control и шпаргалку по FFmpeg.
Context-Aware Encoding: Ещё Одно Измерение
Per-title и per-scene смотрят на контент. Юрий Резник из Brightcove, который и ввёл термин, ещё в 2017 году объяснил: имеет смысл смотреть и на контекст – на популяцию устройств, экранов и сетей, на которые это видео раздаётся. Если 80% ваших зрителей смотрят на мобильном и никогда не доходят до 720p+, верхние ступени 4K и 1440p – это просто бесполезный warm-up для CDN. Если ваша аудитория сосредоточена в регионе с медианной полосой ~4 Mbps, две ступени по 8 и 12 Mbps кормят меньшинство с оптоволокном за счёт лишних кодирований.
Context-aware encoding (CAE) берёт per-title или per-scene лестницу и подрезает / сдвигает её на основе аналитики аудитории: убирает ступени, которые никто не смотрит, перемещает остальные ближе к модальной полосе и пересчитывает целевой VMAF под размер экрана. В работе Резника для SMPTE 2023 года заявлено дополнительное сокращение на 10–20% поверх per-title, если CAE настроен на реальные данные аудитории, а не на предполагаемые. Цена – операционная: нужна аналитика воспроизведения, идущая обратно в пайплайн кодирования, и нужно перекодировать, когда состав аудитории меняется.
Live Streaming Меняет Правила
Per-title придумали для VOD, где файл лежит на диске и анализировать его можно час. Live меняет три ограничения разом: нет цельного файла для анализа, бюджет задержки в секундах, и контент может за один shot перейти от спокойного к хаотичному (вспомните полупропускной отчёт в перерыве, после которого камера возвращается на поле). В продакшене сложилось три адаптации:
Chunk-level адаптация. Bitmovin, Mux и AWS Elemental MediaLive поддерживают chunk-level rate control, где лестница фиксирована при старте стрима, но энкодер каждого сегмента целится в чуть отличающийся битрейт на основе короткого lookahead. Экономия обычно 5–15%.
Audience-adaptive encoding. Mux крутит модель, наблюдающую за входящей телеметрией плееров, и постепенно сдвигает лестницу прямо во время стрима – ступени, которые никто не выбирает, выпиливаются или заменяются. Это ближе к CAE, чем к per-title.
Online per-scene encoding (OPSE). Академическая работа ATHENA Christian Doppler Laboratory в 2022 году показала подход, где каждый поступающий chunk матчится с предвычисленной библиотекой репрезентативных сцен, и лестница берётся у ближайшего матча. Заявленная экономия приближается к 25% поверх статического live, при суб-секундной дополнительной задержке.
Для low-latency форматов – LL-HLS или WebRTC – бюджет на lookahead падает ниже секунды, так что большинство продакшен-систем сегодня скатываются к аккуратно подобранной audience-adaptive фиксированной лестнице с per-stream тюнингом, а не к полноценной per-scene оптимизации.
Где Здесь Фора Софт
Мы строим стриминговые видеопродукты: OTT- и интернет-ТВ-каталоги, где CDN-затраты должны быть предсказуемыми; платформы видеоконференций, где идёт борьба за каждую миллисекунду полосы; e-learning-системы, где лекции варьируются от захвата слайдов до камеры-плюс-доска; и продукты видеонаблюдения и телемедицины, где полосу оплачивает клиент. В каждой из этих вертикалей правильная стратегия per-title или per-scene имеет другую форму. Лекционная платформа может крутить brute-force per-title ночью на каждом аплоаде – лекции редко смотрят в прямом эфире. Live-спорт OTT нуждается в neural-inference per-title плюс context-aware подрезании. Телемедицинское приложение нуждается только в context-aware – контент равномерен, а сеть скачет. Подбор правильной комбинации – одно из решений, через которое мы проходим с каждым новым проектом на старте.
Ключевые Выводы
- Битрейтная лестница – это набор пар (разрешение, битрейт), которые предлагает стрим; фиксированная лестница тратит биты на простой контент и обделяет сложный.
- Per-title encoding строит лестницу под видео, сэмплируя сетку rate-quality и идя по выпуклой оболочке; типичная экономия 20–50% при том же качестве.
- Per-scene (shot-based) режет видео на shots и даёт каждому свой битрейт, добавляя ещё 10–20% поверх per-title.
- Существуют три варианта реализации: brute-force, lookahead-плюс-модель и neural-network инференс – выбор по бюджету и требованию к задержке.
- Context-aware encoding подрезает лестницу по реальным устройствам и сетям аудитории и ложится поверх per-title.
- Live-стримы используют chunk-level или audience-adaptive варианты, потому что цельного файла для анализа нет.