Битрейт-лестница: классическая Netflix, per-title, per-shot

TL;DR

Битрейт-лестница – это набор заранее закодированных версий видео разного качества, из которого плеер выбирает подходящую во время адаптивного стриминга. По умолчанию в 2014 году для каждой статьи использовалась одна и та же лестница – семь-восемь ступеней на каждый контент, – что одновременно приводило к перерасходу полосы пропускания на простом материале и ограничению качества на сложном. В 2015 году Netflix внедрил подход per-title, заменив единую лестницу на content-aware лестницу для каждого фильма, что позволило сократить затраты на хранение и доставку на 15–20% при неизменном воспринимаемом качестве. В 2018 году расширение per-shot дало ещё 10–15% экономии, обеспечив каждой сцене собственные оптимальные параметры кодирования. ИИ-инструменты построения convex hull, появившиеся в 2024–2026 годах, подняли экономию ещё выше и одновременно резко снизили инженерные затраты на создание лестниц. В статье подробно объясняется, как работает каждое поколение решений, с цифрами, компромиссами и реальными продакшен-решениями.

Кому и зачем это нужно

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

Что такое битрейт-лестница на самом деле

Битрейт-лестница – это набор заранее закодированных версий одного и того же видео, каждая из которых имеет своё разрешение и битрейт. Этот список содержится в манифесте – небольшом текстовом файле, который плеер загружает первым. Для HTTP Live Streaming (HLS) манифест представляет собой multi-variant playlist с расширением .m3u8; нормативный документ – стандарт IETF RFC 8216, §4.3.4.2. В случае Dynamic Adaptive Streaming over HTTP (DASH) манифест называется Media Presentation Description и имеет расширение .mpd; нормативный документ – стандарт ISO/IEC 23009-1:2022.

Каждая заранее закодированная версия называется ступенью (rung), и у каждой ступени есть битрейт (количество бит в секунду, которые использует версия), разрешение (ширина × высота в пикселях), кодек (H.264, HEVC, VP9, AV1), частота кадров и связь с аудиоверсиями. Плеер выбирает одну ступень за раз и переключается при изменении сети. Тайтл VOD 1080p в 2026 году обычно отгружается с 6–9 ступенями. Live-событие – с 4–7. Short-форм видео для социальных сетей – с 3–4.

Лестница нужна потому, что одного сетевого состояния не существует. Пользователь на 50 Mbps оптике может взять 6,000 kbps на верхней ступени; пользователь на медленном 4G – 800 kbps. Лестница – это контракт, который позволяет обоим смотреть один и тот же тайтл, не отдавая платформе два разных файла.

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

Классическая фиксированная лестница – 2014 год и мир, унаследованный от Apple

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

Эталонная лестница, которую Apple много лет публиковала в спецификации HLS Authoring, состояла из девяти ступеней. Apple до сих пор поддерживает и обновляет этот документ – на момент написания последняя ревизия датирована 2025-09 – и описание лестницы содержится в разделе §2.7.

Apple в спецификации до сих пор описывает это как «initial encoding targets for typical content delivered via HLS». Слово «initial» здесь играет ключевую роль: Apple подчёркивает, что это лишь отправная точка, а не окончательный ответ. Большинство стриминговых платформ в 2014–2015 годах восприняли это именно как готовый ответ.

Любую фиксированную лестницу определяют три правила, которые сохраняются практически без изменений в per-title и per-shot.

Правило 1 – геометрический шаг. Соседние ступени отстоят друг от друга примерно в 1.5× по битрейту, не равномерно. Шаг от 400 kbps к 600 kbps – это 50% прирост, который пользователь увидит; шаг от 4,000 kbps к 4,200 kbps – 5%, который в основном тратит энкодерное время. У Apple-лестницы соотношения между 1.4× и 1.6×.

Правило 2 – разрешение движется вместе с битрейтом. Поток 400 kbps при разрешении 1920×1080 выглядит хуже, чем 400 kbps при 640×360, потому что энкодеру приходится распределять ограниченный битовый бюджет по слишком большому числу пикселей. Существует так называемое «колено» – точка, выше которой увеличение количества пикселей перестаёт заметно улучшать качество при фиксированном битрейте. Классическая лестница разрешений маскирует это колено, объединяя две-три ступени на высоком разрешении вверху и снижая его внизу.

Правило 3 – спуск по одной ступени за раз. Плеер, который падает с 4,500 kbps сразу до 750 kbps, даёт заметный рывок; переход 4,500 → 3,000 → 1,750 скрывает изменение. Лестница должна быть достаточно плотной, чтобы спуск был плавным, и достаточно разреженной, чтобы стоимость энкодера оставалась разумной.

Проблема фиксированной лестницы – в её базовом допущении, что каждому видео требуется одна и та же зависимость «битрейт – качество». Статичный мультфильм и динамичный спортивный матч одинаково хорошо смотрятся на 2 000 kbps, но при этом используют совершенно разные настройки. Мультфильму едва ли нужно 1 000 kbps; спортивному видео требуется 3 500 kbps, чтобы избежать блочности. Фиксированная лестница либо переплачивает за мультфильм, либо не обеспечивает нужного качества для спорта.

Математика перерасхода

Возьмите 1000 часов мультфильма и 1000 часов экшена. На фиксированной лестнице битрейтов оба формата кодируются одинаково. Экшен-тайтл заполняет верхнюю ступень в 4500 кбит/с полезной детализацией; мультфильм же использует эти биты для плоских поверхностей и медленных градиентов, которые любой энкодер сжимает легко.

Прикидка на обороте конверта: если 30% каталога платформы – это «лёгкий» контент (анимация, слайдовые лекции, talking head), а фиксированная верхняя ступень установлена на уровне 4 500 kbps, то платформа тратит примерно 4 500 × 30% = 1 350 kbps избыточной полосы на треть часа каждый раз, когда зритель смотрит верхнюю ступень. На 1 миллиард часов просмотра в год – типично для среднего стриминг-проекта – это составляет около 600 петабайт избыточного egress. При цене CDN в 2026 году в диапазоне $0.005–$0.015 за гигабайт – где-то от $3 до $9 миллионов в год – платформа платит за полосу, которая фактически не используется.

Именно это число Netflix использовала в атаке в 2015 году.

Перетайтовое кодирование – Netflix 2015 и выпуклая оболочка

В декабре 2015 года Netflix опубликовала пост Per-Title Encode Optimization в своём инженерном блоге. Основная идея: единая фиксированная лестница битрейтов ошибочна, поскольку у каждого контента своё соотношение «битрейт – воспринимаемое качество», и платформа должна подбирать параметры кодирования индивидуально для каждого тайтла. По данным Netflix, такой подход позволил сэкономить 15–20% пропускной полосы при неизменном уровне VMAF – метрики Video Multi-Method Assessment Fusion, которую Netflix представила ранее в том же году.

Механизм – перебор, но дисциплинированный перебор.

Как работает per-title-кодирование, по шагам

Шаг 1 – много пробных энкодов. Для каждого видеоэнкодер выполняет несколько пробных проходов по сетке разрешений (обычно пять–семь шагов, от 1920×1080 до 320×180) и при различных значениях QP внутри каждого разрешения. Типичная сетка для одного полнометражного фильма включает 30–100 пробных энкодов.

Шаг 2 – измерение качества на каждом пробном проходе. Каждый пробный энкод декодируется и оценивается по оригиналу с помощью метрики воспринимаемого качества. Netflix использует VMAF, а некоторые вендоры – PSNR или SSIM. На выходе получается таблица троек (разрешение, битрейт, качество).

Шаг 3 – отметить точки и найти convex hull. Каждый пробный энкод отображается точкой: битрейт – по оси X, качество – по оси Y. Каждое разрешение формирует свою кривую – обычно возрастающую линию, которая на высоких битрейтах выходит на плато. Самое низкое разрешение выигрывает в левой (низкобитрейтной) части графика, самое высокое – в правой (высокобитрейтной). Внешняя огибающая всех кривых – самая правая точка на каждом уровне качества – и есть convex hull: набор пар (битрейт, разрешение), обеспечивающих максимально возможное качество при заданном битрейте.

Шаг 4 – выбор точек на hull и построение лестницы. На convex hull выбираются от пяти до девяти точек на тех уровнях качества, которые платформа планирует отгружать; эти точные пары (разрешение, битрейт) становятся ступенями лестницы.

Результат – лестница, специфичная для контента. У мультфильма лестница может заканчиваться на 2 000 kbps при 1080p, потому что энкодер укладывает качество 1080p в этот битрейт. Лестница спортивного матча с динамичными сценами может требовать 6 500 kbps, чтобы достичь того же VMAF при 1080p. Одинаковое качество, разные битрейты, разные ступени.

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

Цифры Netflix и что они означают

Пример из статьи Netflix 2015 года: анимационный фильм Boss Baby перешёл с фиксированной скорости 5,800 kbps на верхнюю ступень 2,000 kbps в per-title-лестнице без заметной потери качества. Высокодинамичный фильм Bright сохранил верхнюю ступень в диапазоне 4,500–5,800 kbps. По данным каталога, средняя экономия полосы пропускания при неизменном VMAF составила 20%.

Это единственное число – 20% полосы при том же качестве – сделало per-title-кодирование индустриальным стандартом. Для стриминг-платформы с годовыми затратами на egress в $50 миллионов 20% экономии – это $10 миллионов в год чистой маржи, возвращённой одним инженерным проектом.

Где per-Title в 2026 году

Per-title-кодирование – индустриальный стандарт с 2019 года. Вендоры, которые его отгружают:

• Внутренний пайплайн Netflix, оригинальный, до сих пор используется в продакшене на уровне всего каталога (~250 000 часов контента).
• Bitmovin Per-Title Encoding, коммерческий продукт, сообщает о двузначной месячной экономии для VOD-клиентов в кейсах 2018–2025 годов.
• Mux Instant Per-Title, который строит bitrate-лестницу за один быстрый пробный проход вместо полной сетки тестовых энкодов, жертвуя небольшой частью оптимальности ради существенно меньшей стоимости кодирования.
• AWS Elemental MediaConvert с QVBR (Quality-Defined Variable Bitrate) и автоматическим ABR-режимом, который приближает поведение per-title без явного поиска выпуклой оболочки.
• Открытые подходы, прежде всего через AOM-Edge benchmark, Bitmovin Per-Title Bitrate Ladder Benchmark Tool и собственные пайплайны на базе FFmpeg.

В отчёте Bitmovin Video Developer Report 2025 года (опрос 167 разработчиков из 34 стран) per-title и multi-codec названы двумя основными способами сокращения расходов в ближайшие два года. Сигнал очевиден.

Per-shot-кодирование – Netflix 2018 и Dynamic Optimizer

Per-title рассматривает 90-минутный фильм как одну кривую «битрейт – качество». Это ошибка другого рода: внутри одного тайтла медленной диалоговой сцене нужно меньше бит, чем погоне со взрывами и дождём. Per-title-лестница заставляет обе сцены делить один и тот же битрейт – диалог тратит биты, которые ему не нужны, а погоня получает меньше, чем заслуживает, и теряет в качестве, проявляя блочность.

В марте 2018 года Netflix опубликовала работу Dynamic Optimizer – A Perceptual Video Encoding Optimization Framework. Идея заключается в следующем: разбить видео на сцены (непрерывные последовательности между жёсткими склейками), для каждой сцены построить небольшой поиск по выпуклой оболочке и позволить кодировщику на уровне сцены выбирать битрейт и разрешение, наиболее подходящие именно этой сцене, а не всему фильму. В результате экономия по сравнению с per-title оптимизацией в среднем составила ещё 10–15% при неизменном VMAF.

Как работает per-shot-кодирование

Шаг 1 – детекция shots. Процесс детекции shots проходит по мастер-файлу и выявляет границы – резкие склейки, где один ракурс заканчивается, а следующий начинается. Полнометражный фильм продолжительностью 90 минут обычно содержит 800–1500 shots; эпизодическая драма – 600–1200; спортивная трансляция – тысячи микро-шотов и часто обрабатывается фиксированными сегментами вместо полноценной детекции.

Шаг 2 – per-shot convex-hull-поиск. Для каждого кадра выполняется тот же перебор пробных кодировок, что и в per-title-пайплайне, но на значительно меньшем фрагменте (1–30 секунд контента). Каждая пробная кодировка оценивается по VMAF.

Шаг 3 – выбор оптимальной точки при глобальном ограничении. Энкодер решает задачу глобальной оптимизации: выбрать для каждого shot одну пару (разрешение, битрейт) так, чтобы совокупность всех таких выборов обеспечивала максимально возможное среднее качество при заданном общем битрейте. Математически это задача выпуклой оптимизации с ограничениями; в статье Netflix она формулируется с помощью лагранжевой релаксации.

Шаг 4 – склейка shots в один поток на ступень. Каждая ступень итоговой лестницы представляет собой конкатенацию per-shot-выборов, все они имеют один и тот же номинальный целевой битрейт, но разные компромиссы – по разрешению и сложности – от сцены к сцене. Пакетировщик воспринимает результат как единый непрерывный файл.

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

Что отгружено в продакшене

Netflix внедрила dynamic-optimizer-кодирование для отдельных тайтлов каталога в 2018 году, а с 2020 года активно использует его для UHD/4K-контента. К 2026 году технология применяется в продакшене у Netflix, Disney+, Warner Bros. Discovery, YouTube (под внутренними названиями), а также предоставляется компаниями Bitmovin и Brightcove в качестве коммерческой функции.

Инженерная стоимость реальна. Подход per-title обычно увеличивает вычислительную нагрузку энкодерного пайплайна в 2–4 раза по сравнению с фиксированной лестницей; per-shot добавляет ещё 3–8×. Для небольшого каталога с миллионами просмотров на один тайтл экономия полосы пропускания перекрывает затраты на кодирование. В случае long-tail-каталога с тысячами тайтлов и редкими просмотрами математика меняется: полный per-shot-расчёт для тайтла, который смотрят 10 раз в год, может никогда не окупить энкодерные расходы.

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

Поколение 2024–2026 – AI convex hull, per-frame, instant per-title

К 2024 году стало очевидно, что ограничение per-shot-кодирования заключается в следующем: энкодер всё ещё вынужден перебирать brute-force-сетку пробных энкодов для каждого кадра. На большом каталоге это составляет миллионы вычислительных часов в год. Инструменты построения лестницы, появившиеся в 2024–2026 годах, как раз направлены на решение этой проблемы.

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

В 2024 году появилась серия исследований, использующих лёгкие признаки сложности контента – пространственную детализацию, временное движение, перцептивную энтропию клипа – для предсказания положения convex hull без перебора вариантов кодирования. Статья 2024 года Optimal Transcoding Resolution Prediction for Efficient Per-Title Bitrate Ladder Estimation (Telli et al., arXiv:2401.04405) показывает, что один быстрый пробный проход и обученный предиктор воспроизводят результат brute-force convex hull в среднем с погрешностью 1% по VMAF, затрачивая менее 5% вычислительных ресурсов энкодера.

Статья 2024 года Constructing Per-Shot Bitrate Ladders using Visual Information Fidelity (arXiv:2408.01932) применяет аналогичный подход для per-shot оптимизации, используя метрику Visual Information Fidelity (VIF) как более быструю альтернативу VMAF при поиске оптимальных битрейтов. Обзор 2025 года в журнале ACM Multimedia Computing от Sotirakis et al. ("Convex Hull Prediction Methods for Bitrate Ladder Construction") систематизирует семейство методов – варианты реализованы в Akamai, Ericsson, Mux и Bitmovin – и показывает, что лучшие предикторы 2025 года восстанавливают 85–95% экономии полосы пропускания на уровне per-shot при вычислительных затратах в 10–20 раз ниже, чем у полного перебора (brute-force пайплайна).

Instant per-title и probe-based пайплайны

Подход Mux Instant Per-Title, представленный в 2018 году и доработанный к 2024 году, строит per-itle-лестницу на основе одного быстрого анализа источника и предварительно обученной регрессионной модели. Компромисс очевиден: теряется 1–3 % оптимальности по сравнению с полным перебором выпуклой оболочки (brute-force convex hull), но экономится 5–10 раз вычислительных ресурсов энкодера. Для платформ с длинным хвостом каталога и миллионами видео это единственный экономически целесообразный per-title-подход.

Перекодирование на уровне кадров и адаптивное по содержанию

Несколько систем 2025–2026 годов идут дальше per-shot и применяют идею на уровне per-frame или per-group-of-pictures. Энкодер Visionular Aurora1, AOM-варианты AV1 и per-scene-режим Bitmovin в 2026 году все предлагают адаптацию битрейта на уровне кадра. Эмпирическая экономия по сравнению с per-shot незначительна – всего 3–7% дополнительного выигрыша при том же VMAF в опубликованных бенчмарках, – а инженерная сложность существенно возрастает. Для большинства платформ в 2026 году per-shot остаётся оптимальным решением.

Как выглядит дефолт 2026 года

Для инженера стриминга, создающего новую платформу в 2026 году, правильным выбором по умолчанию будет:

• Per-title-кодирование для каждого контента с ожидаемым количеством просмотров ~10 000+ за всё время. Затраты на энкодинг окупаются за несколько месяцев.
• Per-shot-кодирование для топового каталога и прямых трансляций с высокой аудиторией. Дополнительная экономия по сравнению с per-title-кодированием вполне реальна.
• Прогнозирующее / пробное per-title-кодирование для «длинного хвоста». Не запускайте полную переборную сетку на материале, который посмотрят всего 100 раз.
• Чистая фиксированная лестница – только как резервный вариант – для слишком коротких источников или ранних прототипов.

Выбор верхней и нижней ступени

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

Верхняя ступень

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

• Player telemetry на существующем трафике. Какой процент сессий доходит до верхней ступени? Если меньше 5% удерживают её – верхняя ступень декоративна; она стоит хранилища и энкодерного времени, но никого не обслуживает. Выведите.
• Потолок кодека. H.264 перестаёт давать видимое улучшение примерно на 8–10 Mbps для 1080p, 20–25 Mbps для 4K. HEVC – около 5–6 Mbps для 1080p, 12–15 Mbps для 4K. AV1 – около 3.5–4.5 Mbps для 1080p, 8–10 Mbps для 4K. Не стройте верхнюю ступень выше видимого потолка.
• Устройство просмотра. 4K-ступень пропадает на телефоне, но 1080p-ступень пропадает на 4K-телевизоре. Если аудитория с уклоном в ТВ, поднимайте верхнюю ступень; если в мобайл – ограничьте.

Нижняя ступень

Правильная нижняя ступень – это битрейт, который вообще воспроизводится на самой медленной реалистичной сети вашей аудитории. В 2026 году для глобального стриминга ответ – 200–400 kbps при разрешении 240p–360p. Для внутреннего стриминга только по широкополосному интернету достаточно 600–800 kbps при 480p. На корпоративной видеоплатформе с гарантированной скоростью не менее 5 Mbps нижняя ступень может достигать 1,500 kbps.

Ошибка – задрать нижнюю ступень в погоне за «визуальным качеством». Поток 480p на 800 kbps восстанавливается, а вот полного отсутствия потока не избежать, если следующая ступень – 1,500 kbps, а у пользователя закончились мобильные данные.

Пример работы – построение лестницы для драмы 1080p

Пройдёмся по конкретной сборке. Тайтл – 90-минутная драма 1080p со смешанным контентом: медленные диалоги и несколько action-сцен. Аудитория: 60% smart-TV, 30% ноутбуки, 10% мобайл. Кодек: HEVC mainline; H.264 как companion для совместимости.

Шаг 1 – выбор сетки разрешений. 1920×1080, 1280×720, 854×480, 640×360, 426×240. Эти пять разрешений охватывают основные размеры экранов целевой аудитории.

Шаг 2 – выбор сетки битрейтов. Пробные кодировки при значениях constant rate factor 21, 24, 27, 30, 33, 36, 39 (HEVC). Каждая комбинация «разрешение × CRF» даёт пробную кодировку и значение VMAF.

Шаг 3 – прогон пробных энкодов. 5 × 7 = 35 попыток на кадр. Для сборки per-title это 35 попыток на весь фильм. Для сборки per-shot с 1 000 обнаруженных кадров – 35 000 попыток, но каждая короткая. На 32-ядерной ферме энкодеров проход per-title занимает несколько минут; per-shot – несколько часов.

Шаг 4 – построение выпуклой оболочки и сэмплирование. Энкодер определяет точки, в которых (1080p HEVC, 4,200 kbps), (1080p HEVC, 2,800 kbps), (720p HEVC, 1,650 kbps), (720p HEVC, 1,100 kbps), (480p HEVC, 700 kbps), (360p HEVC, 420 kbps) и (240p HEVC, 250 kbps) лежат на выпуклой оболочке. Эти точки становятся семью ступенями кодирования HEVC.

Шаг 5 – генерация H.264-лестницы. Для достижения того же значения VMAF, что и у HEVC, H.264 требует примерно в 1,5–1,8 раза больше битрейта. Соответствующие ступени H.264 составляют 6 500 / 4 500 / 2 600 / 1 750 / 1 100 / 650 / 400 кбит/с при тех же разрешениях.

Шаг 6 – публикация манифеста. HLS multi-variant playlist или DASH MPD перечисляют все 14 уровней (7 HEVC + 7 H.264) с указанием строк кодеков, атрибутов пропускной способности и разрешения. Устройства Apple в первую очередь выбирают уровни с кодеком HEVC в соответствии со своим порядком предпочтений кодеков; остальные устройства используют H.264.

Лестница из 14 ступеней выглядит тяжёлой – и не зря. Стоимость: одноразовые затраты на энкодерное время и постоянное хранение; выгода: все устройства, сети и предпочтения кодеков охватываются единым манифестом. Если экономия от HEVC на аудитории составляет 30%, такая лестница окупается за месяцы за счёт egress.

Live-стриминг – лестница, которую невозможно тонко настроить

Записанный ролик проходит полный поиск выпуклой оболочки. Live-трансляция – нет: времени на пробные энкодинги перед каждым кадром не хватает. Сегодня live-лестницы отгружаются в трёх вариантах.

Вариант 1 – статичная live-лестница. Ручная настройка фиксированной лестницы – так организовывался каждый прямой эфир в 2018 году. Три–пять уровней. Дёшево, но неоптимально для тяжёлого контента, например, спорта.

Вариант 2 – live per-title. Короткое окно пробной трансляции – обычно первые 5–30 секунд – используется для настройки кодировочной лестницы под оставшуюся часть эфира. Подходит для предсказуемых трансляций (например, 90-минутный футбольный матч с стабильными характеристиками движения). Неустойчив к непредсказуемому контенту (например, talk-шоу, которое внезапно переходит на новостной сегмент).

Вариант 3 – адаптивная live-лестница. Live-энкодер непрерывно отслеживает сложность контента (векторы движения, частоту смены сцен) и динамически подстраивает огибающую битрейта и набор ступеней в рамках заданных ограничений. Реализации таких подходов предлагают AWS Elemental QVBR live, Bitmovin adaptive live encoding и Harmonic VOS real-time per-scene mode.

Главное число: live per-title и адаптивные live-лестницы экономят 10–15 % полосы по сравнению со статичными при примерно 20 % дополнительной нагрузке на энкодер и более сложной операционной модели.

Типичные ошибки и как их избежать

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

• Верхняя ступень, до которой никто не дотягивается. 12 Mbps – 4K-ступень в стриминговом сервисе, где у медианного зрителя канал 25 Mbps, но под нагрузкой проседает до 10 Mbps. Эта ступень указана в манифесте, за неё платит энкодер на каждый тайтл, но почти никто её не использует – плеер не может её удержать. Проведите аудит телеметрии плеера и исключите любую ступень, которую запускают менее чем в 5% сессий.
• Слишком высокая нижняя ступень. Установление 1,5 Mbps в качестве минимальной скорости для глобальной мобильной аудитории – ошибка. При первом же падении соединения до 600 kbps плееру некуда снижаться, кроме как в остановку (stall). Решение – добавить fallback-ступень ниже 500 kbps, даже если она выглядит плохо: лучше плохо воспроизводимый поток, чем отсутствие воспроизведения.
• Равномерный шаг битрейтов вместо геометрического. Лестница 500 / 1 000 / 1 500 / 2 000 / 2 500 kbps тратит ресурсы энкодера сверху (шаг 2 000 → 2 500 – всего 25%) и даёт плееру слишком мало вариантов снизу (шаг 500 → 1 000 – 100%). Используйте геометрический шаг 1,5×.
• Per-title без проверки long tail. Построение полного per-title-пайплайна методом перебора для каталога из 50 000 тайтлов, где у медианного – всего 200 просмотров, приводит к тому, что затраты на энкодинг перевешивают экономию трафика. Для «хвоста» используйте probe-based per-title (например, Mux Instant или аналог).
• Фиксированная лестница для live-спорта. Спортивный контент сильно варьируется по сложности: медленный pre-match warm-up и динамичный момент breakaway требуют совершенно разных битовых бюджетов. Фиксированная live-лестница переплачивает на разогреве и не справляется с пиками нагрузки. Минимум – live per-title.

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

Мы разрабатываем видеостриминг, WebRTC, конференц-связь, видеонаблюдение, e-learning и OTT-платформы с 2005 года, и решения по битрейт-лестницам из этой статьи – одни из первых, которые мы внедряем на каждом новом проекте. Выбор между фиксированной, per-title и per-shot стратегиями редко бывает «лучшим» – это всегда правильный компромисс с учётом размера каталога, бюджета на кодирование, сетевых условий аудитории и сроков запуска. Мы регулярно поставляем per-title для платных OTT-клиентов и live per-title для спортивных трансляций; а также фиксированные трёхступенчатые лестницы для ранних образовательных платформ, потому что там ещё не наработана достаточная инженерная база. Дисциплина остаётся одинаковой в обоих случаях: сначала измеряем, потом оптимизируем.

Ключевое

• Битрейт-лестница – это набор заранее закодированных версий видео, из которого плеер выбирает оптимальную для каждого сегмента.
• Фиксированная лестница 2014 года перерасходует битрейт на простом контенте и не обеспечивает нужного качества на сложном.
• Netflix per-title (2015) обеспечивает первые 15–20% экономии полосы пропускания при неизменном уровне VMAF.
• Netflix per-shot (2018) добавляет ещё 10–15% экономии, настраивая битрейт-лестницу под каждую сцену.
• ИИ- и probe-инструменты (2024–2026) восстанавливают почти всю экономию per-shot, но при значительно меньших затратах на кодирование.
• Стандарт 2026 года: per-title для всего каталога, per-shot – для топовых тайтлов (tier-1), probe-based – для длинного хвоста.

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

• ABR-стриминг: подробное объяснение без маркетинговых слов – плеерный механизм, который работает с «лестницей» битрейтов.
• Throughput-based ABR-алгоритмы – как плеер выбирает подходящую ступень в реальном времени.
• Packaging подробно: от выхода энкодера до манифеста – как закодированные уровни превращаются в воспроизводимый манифест.

CTA

• Поговорить со streaming-инженером – забронируйте 30-минутный звонок с командой, чтобы обсудить стратегию битрейт-лестницы.
• Посмотреть наши кейсы – OTT, e-learning и live-проекты Фора Софт.
• Скачать рабочий лист по дизайну битрейт-лестницы – одностраничный аудит формы лестницы, верхней и нижней ступеней, mix кодеков и амортизации стоимости энкодера. Скачать (PDF)