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

TL;DR

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

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

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

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

Битрейт-лестница – это список заранее закодированных версий одного и того же видео, каждая со своей комбинацией разрешения и битрейта. Список лежит внутри манифеста – небольшого текстового файла, который плеер скачивает первым. Для 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-form social-видео – с 3–4.

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

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

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

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

Эталонная лестница, которую Apple много лет публиковала в HLS Authoring Specification, имела девять ступеней. 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, чтобы избежать блочности. Фиксированная лестница либо переплачивает за мультфильм, либо недодаёт спорту.

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

Возьмите 1,000 часов мультфильма и 1,000 часов action. На фиксированной лестнице оба кодируются на одних и тех же битрейтах. Action-тайтл заполняет верхнюю ступень 4,500 kbps полезной детализацией; мультфильм тратит эти биты на плоские поверхности и медленные градиенты, которые любой энкодер сжимает дёшево.

Прикидка на обороте конверта: если 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 году.

Per-title-кодирование – Netflix 2015 и convex hull

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

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

Как работает 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 и что они означают

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

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

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

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

• Внутренний пайплайн Netflix, оригинатор, до сих пор в продакшене на масштабе каталога (~250,000 часов контента).
• Bitmovin Per-Title Encoding, коммерческий продукт, отчитывается о двузначной месячной экономии для VOD-клиентов в кейсах 2018–2025 годов.
• Mux Instant Per-Title, который строит лестницу на одном быстром probe-проходе вместо полной сетки пробных энкодов и обменивает небольшую часть оптимальности на гораздо меньшую стоимость энкодера.
• AWS Elemental MediaConvert с QVBR (Quality-Defined Variable Bitrate) и automated ABR mode, который аппроксимирует per-title-поведение без явного convex-hull-поиска.
• Open-source-подходы, прежде всего через AOM-Edge benchmark, Bitmovin Per-Title Bitrate Ladder Benchmark Tool и self-made пайплайны на 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. Идея: разрезать тайтл на shots (непрерывные последовательности между жёсткими склейками), построить небольшой convex-hull-поиск для каждого shot и дать per-shot-энкодеру выбрать битрейт и разрешение, которые лучше всего подходят этой сцене, а не всему фильму. Экономия сверху per-title в среднем составила ещё 10–15% при том же VMAF.

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

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

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

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

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

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

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

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

Инженерная стоимость реальна. Per-title типично увеличивает compute-нагрузку энкодерного пайплайна в 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-сетку пробных энкодов для каждого shot. На большом каталоге это миллионы compute-часов в год. Поколение инструментов построения лестницы 2024–2026 атакует именно эту стоимость.

Predictive convex-hull tools

В 2024 году появилась серия исследований, которые используют лёгкие признаки сложности контента – пространственную детализацию, временное движение, перцептивную энтропию клипа, – чтобы предсказать, где сядет convex hull, без brute-force trial encodes. Статья 2024 года Optimal Transcoding Resolution Prediction for Efficient Per-Title Bitrate Ladder Estimation (Telli et al., arXiv:2401.04405) сообщает, что один быстрый probe-проход плюс обученный предиктор воспроизводят 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 journal от Sotirakis et al. ("Convex Hull Prediction Methods for Bitrate Ladder Construction") каталогизирует семейство – варианты отгружают Akamai, Ericsson, Mux и Bitmovin – и сообщает, что лучшие предикторы 2025 года восстанавливают 85–95% per-shot-экономии полосы при compute в 10–20× ниже brute-force-пайплайна.

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

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

Per-frame и content-aware-кодирование

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

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

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

• Per-title-кодирование для каждого тайтла с ожидаемыми ~10,000+ lifetime-просмотрами. Энкодерная стоимость отбивается за месяцы.
• Per-shot-кодирование для tier-1-каталога и live-трансляций с высокой посещаемостью. Маржинальная экономия сверху per-title реальна.
• Predictive / probe-based per-title для long tail. Не запускайте brute-force-сетку на тайтле, который посмотрят 100 раз.
• Чистая фиксированная лестница – только как fallback – для слишком короткого источника или ранних прототипов.

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

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

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

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

• 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. Для внутреннего broadband-only стриминга – 600–800 kbps на 480p достаточно. Для корпоративной видеоплатформы с гарантированными 5 Mbps минимум нижняя ступень может быть 1,500 kbps.

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

Worked example – построение лестницы для драмы 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 trials на shot. Для per-title-сборки это 35 trials на весь фильм. Для per-shot-сборки с 1,000 обнаруженных shots – 35,000 trials, но каждый короткий. На 32-ядерной энкодерной ферме per-title-проход занимает несколько минут; per-shot – несколько часов.

Шаг 4 – построение convex hull и сэмплирование. Энкодер находит точки, где (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) лежат на hull. Они становятся семью HEVC-ступенями.

Шаг 5 – генерация H.264-companion-лестницы. H.264 нужен примерно в 1.5–1.8× битрейт HEVC при том же VMAF. H.264-ступени становятся 6,500 / 4,500 / 2,600 / 1,750 / 1,100 / 650 / 400 kbps на тех же разрешениях.

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

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

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

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

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

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

Вариант 3 – адаптивная live-лестница. Live-энкодер непрерывно мониторит сложность контента (motion vectors, частоту смены сцен) и подстраивает огибающую битрейта и набор ступеней в рамках ограничений. 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 под нагрузкой. Ступень есть в манифесте, энкодер платит за неё на каждый тайтл, и почти никто её не играет, потому что плеер не может удержать. Сделайте аудит player telemetry; выведите любую ступень, которую играет меньше 5% сессий.
• Слишком высокая нижняя ступень. 1.5 Mbps как floor на глобальной мобильной аудитории. Первый же раз, когда соединение упадёт до 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. Построение brute-force 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 для long tail.

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

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

CTA

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