ABR-стриминг: подробное объяснение без маркетинговых слов

TL;DR

ABR-стриминг (адаптивный битрейт) – это технология, которая позволяет одному и тому же видео в реальном времени или из библиотеки одинаково плавно играть и на медленном телефоне, и на быстром ноутбуке, и на телевизоре 4K. Видео заранее кодируется в нескольких версиях разного качества, манифест перечисляет их, плеер выбирает версию под текущую сеть и устройство и переключается между ними каждые несколько секунд, не прерывая воспроизведение. Математика ABR проста – выбрать максимальное качество, которое успевает загрузиться в пределах буфера, – а вся инженерия вокруг этой математики и определяет, выигрывает ли продукт у конкурентов. В статье разобраны механика ABR, три семейства алгоритмов решения в продакшене и пять ошибок, которые портят опыт зрителей.

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

Если вы отвечаете за продукт, который доставляет видео – обучающую платформу, телемедицинский сервис, OTT-приложение, систему наблюдения – ABR определяет, работает ли видео для пользователей или они оставляют жалобы в магазинах приложений. Маркетинг, продакт и финансисты сталкиваются с ABR через три его следствия: счёт за CDN, долю буферизации и время старта воспроизведения. Инженеры – через длинный список параметров, у которых нет очевидно правильных значений. Обоим аудиториям нужна одна и та же модель мышления, и эта статья её даёт.

ABR одним предложением

Число, которое показывает, сколько бит в секунду плеер должен скачивать, чтобы видео шло – это битрейт – не константа. ABR – это договорённость о том, что плеер каждые несколько секунд выбирает максимальный битрейт, который сеть ещё успевает доставить. Apple называет это HTTP Live Streaming с multi-variant playlist (RFC 8216, §4.3.4.2). Стандарт MPEG называет это Dynamic Adaptive Streaming over HTTP, сокращённо DASH (ISO/IEC 23009-1:2022). Названия разные, идея одна: одно и то же видео кодируется один раз в нескольких версиях, плеер скачивает по очереди из одной версии и имеет право переключаться между версиями на границе любого сегмента.

То, что отличает ABR от «пользователь сам выбрал 720p» или «сервер определил устройство и отдал одну версию», – это переключение. Решение принимает плеер. Каждые 2–6 секунд плеер задаёт один вопрос – я успеваю скачивать достаточно быстро? – и либо остаётся на текущей ступени, либо двигается на одну вверх или вниз.

Четыре составляющих любой ABR-системы

В любой ABR-системе, независимо от протокола и вендора, есть одни и те же четыре подвижные части. Узнайте их, и остальная часть статьи прочитается сама.

1. Лесенка битрейтов (bitrate ladder). Список заранее закодированных версий одного и того же контента, каждая со своим битрейтом и разрешением. Типичная лесенка для 1080p VoD-фильма содержит 6–9 ступеней: 235 kbps на 416×234, 375 kbps на 640×360, 560 kbps на 768×432, 750 kbps на 960×540, 1050 kbps на 1280×720, 1750 kbps на 1280×720, 2350 kbps на 1920×1080, 3000 kbps на 1920×1080, 4500 kbps на 1920×1080. Эти числа взяты из Apple HLS Authoring Specification (ревизия 2025-09, §2.7); конкретные значения сервисы подстраивают под себя.

2. Пакетировщик (packager). Программа, которая режет каждую закодированную версию на короткие сегменты – обычно по 2, 4 или 6 секунд – и пишет манифест с указанием, какие сегменты принадлежат какой ступени. У HLS манифест – это multi-variant .m3u8, у DASH – один файл .mpd. Open-source-варианты по умолчанию: Shaka Packager и Bento4; коммерческие альтернативы – AWS MediaPackage, Unified Streaming, Wowza.

3. Манифест. Текстовый файл, который плеер скачивает первым. Перечисляет каждую ступень, каждый кодек, каждую звуковую дорожку и дорожку субтитров, а также URL сегментов. Манифест маленький (несколько килобайт), но это контракт: плеер имеет право использовать любую комбинацию, указанную в манифесте, и ничего больше.

4. ABR-алгоритм. Код внутри плеера, который решает, какую ступень скачивать следующей. Это та часть, к которой относятся научные статьи и патентные войны. В продакшен-плеерах используются три семейства алгоритмов, разобранные ниже.

Как разворачивается одна ABR-сессия

Пройдёмся по реальной сессии посекундно – так станет понятнее, что делают эти четыре части.

Пользователь нажал Play. Плеер скачивает манифест – обычно 5–15 килобайт – и парсит его. В манифесте указано, что доступно шесть ступеней от 400 kbps до 5000 kbps и что длительность сегмента – четыре секунды. Плеер выбирает стартовую ступень. Большинство плееров стартуют на одну-две ступени ниже середины лесенки – reference-плеер Apple стартует с ступени, чей битрейт ближе всего к недавно измеренной пропускной способности, с лёгким смещением в сторону «ниже». HLS Authoring Specification (рев. 2025-09, §4.7.5) рекомендует, чтобы стартовый выбор брал ступень, которую устройство гарантированно потянет.

Плеер скачивает сегмент 1 выбранной ступени. Допустим, сегмент – это 4 секунды видео на 1750 kbps, то есть примерно 875 килобайт (1750 kbps × 4 s ÷ 8 бит/байт). На канале 6 Mbps сегмент придёт примерно за 1.2 секунды – намного быстрее, чем те четыре секунды воспроизведения, которые он содержит. Скорость скачивания (6 Mbps) комфортно выше битрейта ступени (1.75 Mbps), и плеер поднимается на ступень выше для сегмента 2.

Плеер скачивает сегмент 2 на 2350 kbps. Скачивание всё равно заканчивается задолго до того, как воспроизведение его догонит; буфер – банк заранее скачанных сегментов, лежащих впереди playhead, – растёт с 4 до 8 секунд. Плеер поднимается ещё на ступень для сегмента 3, и ещё для сегмента 4.

На сегменте 5 плеер дошёл до ступени 4500 kbps. Математика изменилась: каждый 4-секундный сегмент – это 2250 килобайт. На том же канале 6 Mbps скачивание занимает около 3 секунд – всё ещё меньше 4, но запас сократился. Плеер остаётся на этой ступени.

Тут двери лифта открываются, и поезд отъезжает от станции. Телефон пользователя переключается с Wi-Fi на LTE. Измеренная пропускная способность падает с 6 Mbps до 1.8 Mbps. Следующий сегмент на 4500 kbps скачивался бы 10 секунд – больше глубины буфера. Плеер видит эту тенденцию в скользящем среднем и спускается сразу на две ступени до 1750 kbps для следующего сегмента. Качество на несколько секунд падает, буфер выживает, зритель продолжает смотреть.

Это и есть ABR. Всё остальное в статье – детали о том, как именно плеер принимает решение «пропускная способность упала – спустить ступень» хорошо или плохо.

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

Лесенка битрейтов в конкретных цифрах

Лесенка – это меню, из которого выбирает плеер. Хорошую лесенку определяют три правила.

Правило 1 – геометрический шаг. Соседние ступени отличаются примерно в 1.5×, а не равными интервалами. Переход с 400 kbps на 600 kbps – это 50% прироста, который пользователь увидит; переход с 4000 kbps на 4200 kbps – 5% прироста, который в основном тратит впустую время кодировщика. Рекомендованная Apple лесенка (HLS Authoring Specification рев. 2025-09, §2.7) идёт ступенями 235 / 375 / 560 / 750 / 1050 / 1750 / 2350 / 3000 / 4500 kbps – каждое отношение между 1.4× и 1.6×.

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

Правило 3 – шаги переключения не больше 1.5×. Если плеер вынужден спускаться, по возможности он спускается на одну ступень за раз. Прыжок с 4500 kbps сразу на 750 kbps даёт заметный рывок; падение до 3000, а потом, если надо, до 1750 – менее заметно. Некоторые алгоритмы пропускают ступени, чтобы не дать буферу опустеть, – это правильный ход, когда сеть действительно «провалилась».

Первая конкретная лесенка для 1080p VoD-фильма выглядит так. Звук идёт отдельной дорожкой на 128 kbps.

Конкретные числа смещаются для каждого фильма, каждой сцены и каждого кодека – это тема следующей статьи блока Сборка лесенки битрейтов.

Три семейства алгоритмов

Каждый ABR-алгоритм в продакшене сегодня принадлежит к одному из трёх семейств. Они отличаются тем, какому сигналу больше всего доверяют.

Семейство 1 – Throughput-based ABR (по пропускной способности)

Самое простое семейство. Плеер ведёт скользящую оценку недавней пропускной способности – обычно гармоническое среднее последних трёх-пяти сегментов. Чтобы выбрать следующую ступень, плеер делит оценку на коэффициент безопасности (обычно 1.2–1.5) и берёт максимальную ступень, чей битрейт ниже получившегося потолка.

Математика на цифрах: последние три сегмента скачались на 2.8, 3.1 и 2.5 Mbps. Гармоническое среднее – 3 ÷ (1/2.8 + 1/3.1 + 1/2.5) ≈ 2.78 Mbps. Делим на коэффициент 1.25: 2.22 Mbps. Максимальная ступень с битрейтом не выше 2.22 Mbps – это ступень 5 на 2000 kbps. Плеер скачивает её.

Throughput-based ABR – это дефолт в hls.js, в нативном плеере iOS и в большинстве «v1»-реализаций. Быстро запускается, легко рассуждать, предсказуем на стабильных сетях. Хуже работает на «дёрганых» сетях – Wi-Fi с качающейся скоростью – и недоиспользует буфер.

Семейство 2 – Buffer-based ABR (по буферу)

Более консервативное семейство. Плеер игнорирует оценки пропускной способности и смотрит только на текущий уровень буфера – сколько секунд заранее скачанного видео лежит впереди playhead. Правила:

• Буфер ниже порога T_low (например, 5 секунд) → спустить на низкую ступень, чтобы заново его наполнить.
• Буфер между T_low и T_high (например, 5–25 секунд) → линейно интерполировать между низкой и высокой ступенями.
• Буфер выше T_high → взять самую высокую ступень.

Каноническая статья – BOLA (Buffer Occupancy based Lyapunov Algorithm, Spiteri, Urgaonkar, Sitaraman, INFOCOM 2016), в которой доказана аккуратная математическая граница на частоту ребуферов BOLA-плеера при заданной глубине буфера. BOLA с 2018 года – дефолт в dash.js и один из двух вариантов в Shaka Player.

Buffer-based хорошо переживает дёрганые сети, потому что не реагирует на мгновенные просадки – буфер их поглощает. Недоиспользует канал, когда буфер заполнен на верхней ступени, и медленнее реагирует, когда сеть действительно улучшилась.

Семейство 3 – Гибридные ABR

То, что ставится в реальные топовые плееры. Объединяет оценку пропускной способности и модель буфера и выбирает ступень, максимизирующую функцию полезности – обычно взвешенную сумму «качества» (выше ступень) и «стабильности» (без переключений и ребуферов).

Два самых цитируемых гибридных алгоритма – Model Predictive Control (MPC) (Yin, Jindal, Sekar, Sinopoli, SIGCOMM 2015) и FESTIVE (Jiang, Sekar, Zhang, CoNEXT 2012). Продакшен-плееры, публикующие свои алгоритмы, ссылаются на эти статьи как на предков. У Netflix свой проприетарный гибрид; у YouTube тоже. Плеер Mux и веб-плеер LiveKit используют гибридный режим Shaka Player.

Компромисс простыми словами для не-инженера: throughput-based – простой и быстрый, но дёрганый на нестабильных сетях. Buffer-based – гладкий, но медленно поднимается. Гибрид – медленно делается, тяжело отлаживается, лучший для пользователя.

Четвёртое семейство – нейронные ABR – использует обученную нейросеть вместо ручной формулы. Pensieve (Mao, Netravali, Alizadeh, SIGCOMM 2017) был первым широко цитируемым примером, позже Comyco и Kairos двигали уровень техники дальше. В 2026 нейронный ABR ещё не дефолт в продакшене за пределами двух-трёх топовых сервисов, но направление развития именно такое. Подробнее – в следующей статье блока Нейронные и обучаемые ABR.

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

Цифры, которые важны бизнесу

Пять метрик QoE, привязанных к поведению ABR, определяют экономику каждого стримингового продукта.

Start-up time – секунды между «пользователь нажал Play» и «первый кадр на экране». Лидеры держат 1.0–1.5 с; медианное стрим-приложение – 3–5 с. ABR влияет через выбор стартовой ступени – слишком высокая, и первый сегмент долго идёт; слишком низкая, и пользователь видит пикселизацию в первые секунды.

Rebuffer ratio – доля времени просмотра, во время которой вместо видео крутится спиннер. Топовые сервисы целятся ниже 0.4%; Conviva State of Streaming за 2024 даёт мировую медиану около 1.2%. ABR влияет через выбор ступеней, которые сеть действительно тянет.

Average bitrate – средний битрейт фактически воспроизведённого видео. Выше – лучше, до точки, где экран уже не различает разницу. ABR влияет через то, чтобы не сидеть на нижней ступени, когда сеть позволяет больше.

Switches per minute – сколько раз в минуту плеер менял ступень. Каждое переключение – небольшой рывок. Топовые сервисы целятся в меньше одного переключения на две минуты.

Quality-adjusted bitrate – производная метрика, объединяющая битрейт и переключения, обычно с уклоном в стабильность. Это то, что гибридные алгоритмы оптимизируют напрямую.

Эти пять – центральная тема статьи Наблюдаемость плеера и метрики в блоке 7.

Числовой пример от и до

Конкретная арифметика подкрепляет любое утверждение выше. Возьмём 10-минутный VoD с шестиступенчатой лесенкой (400, 750, 1500, 2500, 4000, 6000 kbps), сегментами по 4 секунды, у зрителя сеть стабильно 3.2 Mbps с одним 30-секундным провалом до 1 Mbps в середине.

Всего сегментов = 600 ÷ 4 = 150.

Если бы плеер всё время держал ступень 4000 kbps, суммарно скачалось бы 4000 × 600 ÷ 8 = 300 000 килобайт = 300 МБ. Ёмкость канала на 3.2 Mbps за 600 с = 3200 × 600 ÷ 8 = 240 000 килобайт = 240 МБ. Плеер ребуферил бы 60 секунд – 10% rebuffer ratio. Неприемлемо.

Если бы плеер держал ступень 2500 kbps, суммарно = 187.5 МБ, спокойно в пределах 240 МБ. Провал до 1 Mbps на 30 с стоит примерно (2500 − 1000) × 30 ÷ 8 = 5625 килобайт расхода буфера. Если буфер в начале провала был 30 с × 2500 kbps ÷ 8 = 9375 килобайт – буфер выживает.

Throughput-based-плеер большую часть времени держался бы на 2500 kbps, на время провала спустился бы до 750 kbps и вернулся. Средний битрейт ≈ 2400 kbps. Переключений ≈ 2. Ребуфер = 0.

Buffer-based-плеер пробовал бы подняться выше, когда буфер растёт – возможно, на 20–30 секунд касался бы 4000 kbps до провала, потом упал бы на 1500 kbps, когда буфер вытек. Средний битрейт ≈ 2600 kbps. Переключений ≈ 3. Ребуфер = 0.

Гибридный плеер двигался бы похоже на buffer-based, но с более гладкими переключениями. Средний битрейт ≈ 2650 kbps. Переключений ≈ 2. Ребуфер = 0.

Выигрыш в этом сценарии не огромный – стабильная сеть прощает. Выигрыш максимален на нестабильных мобильных и Wi-Fi-сетях, на которых проходит большая часть реального просмотра.

Live vs VoD – что ABR делает иначе

ABR в VoD-стриминге располагает временем. Весь контент уже закодирован и упакован; плеер может свободно пробовать ступени выше, потому что у сегмента нет дедлайна. ABR в live не имеет такой роскоши – кодировщик выдаёт сегменты в реальном времени, и плеер обязан держаться у live edge, а не отставать.

Важные отличия:

• Глубина буфера меньше. VoD-плеер может держать 60 секунд буфера; low-latency live-плеер целится максимум на 3–6 секунд.
• Переключения консервативнее. Отвалиться от live edge выглядит хуже, чем просадка качества.
• Стартовая ступень ниже. Live-плеер скорее стартует с 720p и стабилизируется, чем стартует с 1080p и ребуферит.
• Chunked CMAF меняет математику. В Common Media Application Format (ISO/IEC 23000-19) с chunked CMAF сегмент может начать идти в плеер ещё во время кодирования. Оценщик пропускной способности должен игнорировать темп кодировщика, который приходит ровно на битрейте ступени, и измерять только сетевую скорость. Это один из самых тяжёлых багов в low-latency-плеерах.

Подробнее – в статьях LL-HLS подробный разбор и LL-DASH и CMAF chunked.

Типичные ошибки, ломающие ABR

Пять ошибок отвечают за большую часть боли с ребуферами в продакшен-стриминге. Следите за ними.

«Ошибка 1 – слишком мало ступеней. Лесенка из трёх ступеней загоняет плеер в уродливые компромиссы. Вверх – каждый шаг большой и заметный, вниз – плеер либо «перепрыгивает», либо ребуферит. Шесть-девять ступеней – лучшая точка для 1080p-фильма.»

«Ошибка 2 – «понтовая» верхняя ступень. Ступень на 10 Mbps, которую не тянет ни одна реальная сеть, – это ловушка для CDN-счёта: пара процентов зрителей до неё мгновенно дотянутся, поймают ребуфер, и плеер потащит их вниз. Если меньше 5% зрителей удерживают ступень – снимите её.»

«Ошибка 3 – игнорировать выбор стартовой ступени. Плееры, всегда стартующие с самой нижней ступени, плохо выглядят в первые три секунды – именно тот период, по которому мозг зрителя решает, «годный» ли сервис. Большинство пользователей решают, остаться или закрыть приложение, в первые десять секунд.»

«Ошибка 4 – доверять оценщику пропускной способности на первом сегменте. Оценщик не работает с нулём данных. Используйте разумный дефолт (пропускная способность последней сессии или консервативная средняя ступень), пока плеер не накопит три-четыре сегмента для усреднения.»

«Ошибка 5 – не измерять переключения. Средний битрейт может выглядеть нормально, даже когда плеер «качает» резкими переключениями; пользователь видит как раз качку, а не среднее. Количество переключений в минуту – метрика первого класса. Отслеживайте её.»

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

Мы с 2005 года сделали 239+ стриминговых продуктов. ABR важен в каждой нашей вертикали – OTT и Internet-TV-приложения, где лесенка битрейтов формирует счёт за CDN; e-learning-платформы, где переключения посреди лекции уводят внимание студента от лектора; телемедицинские консультации, где просадка качества на экране врача в момент диагностического вопроса – клинический риск; системы видеонаблюдения, где десятки потоков делят один аплинк и ABR – единственное, что держит их живыми. Мы настраиваем лесенки, выбираем алгоритмы и перестраиваем наблюдаемость плеера в каждом проекте – и те же пять ошибок выше встречаются чаще всего, когда мы наследуем чужой стек.

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

• ABR стримит одно видео в нескольких битрейтах и даёт плееру выбирать ступень под текущую сеть.
• В любой ABR-системе четыре части: лесенка, пакетировщик, манифест, алгоритм. Узнайте их – остальное детали.
• В продакшене работают три семейства алгоритмов – throughput-based, buffer-based и гибрид. Гибрид побеждает для пользователя.
• Шесть-девять ступеней – лучшая точка; шаг между соседними примерно 1.5×.
• Бизнес ведут пять метрик: start-up time, rebuffer ratio, average bitrate, switches per minute, quality-adjusted bitrate.
• Главные продакшен-ошибки – мало ступеней, понтовая верхняя ступень и отсутствие измерения переключений.

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

• Сборка лесенки битрейтов: Netflix, per-title, per-shot – как именно подбирают ступени для конкретного фильма.
• Buffer-based ABR: BOLA подробно – математика, сделавшая buffer-based строгим.
• Наблюдаемость плеера и метрики, которые катятся в продакшен – как измерять все пять метрик выше.

CTA

• Поговорить со стриминг-инженером – забронируйте 30-минутный звонок с нашей командой стриминга.
• Посмотреть кейсы – почитайте, как мы делали ABR для OTT, e-learning, телемедицины и видеонаблюдения.
• Скачать: чек-лист настройки ABR – одностраничный аудит лесенки, выбора алгоритма, стартовой ступени и наблюдаемости. Скачать чек-лист.