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) рекомендует, чтобы стартовый выбор брал ступень, которую устройство гарантированно потянет.

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

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

На сегменте 5 плеер достиг уровня 4500 кбит/с. Математика изменилась: каждый 4-секундный сегмент теперь составляет 2250 килобайт. На том же канале со скоростью 6 Мбит/с скачивание занимает около 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 выглядит хуже, чем тот же битрейт при 640×360. Существует «излом» – точка, выше которой увеличение количества пикселей уже не улучшает восприятие качества. В современных лесенках битрейта вверху обычно сосредоточены две-три ступени с одинаковым разрешением, а внизу оно постепенно снижается. Эту практику популяризировала компания Netflix – в их инженерном блоге она описана как per-title encoding, поскольку положение «излома» зависит от конкретного контента.

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

Первая конкретная лесенка для 1080p VoD-фильма выглядит следующим образом: звук передаётся отдельной дорожкой со скоростью 128 кбит/с.

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

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

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

Семейство 1 – ABR на основе пропускной способности

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

Математика на цифрах: последние три сегмента скачались со скоростями 2,8, 3,1 и 2,5 Мбит/с. Гармоническое среднее: 3 ÷ (1/2,8 + 1/3,1 + 1/2,5) ≈ 2,78 Мбит/с. Делим на коэффициент 1,25 – получаем 2,22 Мбит/с. Максимальная ступень с битрейтом не выше 2,22 Мбит/с – это ступень 5 на 2000 кбит/с. Плеер выбирает её для скачивания.

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

Семейство 2 – 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 при заданной глубине буфера. С 2018 года BOLA является дефолтным алгоритмом в dash.js и одним из двух вариантов в Shaka Player.

Буферизация хорошо работает в нестабильных сетях, потому что не реагирует на кратковременные просадки – буфер их компенсирует. Однако при полном заполнении буфера канал используется неэффективно, а при улучшении сети система реагирует медленнее.

Семейство 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-ориентированный – простой и быстрый, но «подпрыгивает» на нестабильных сетях. Buffer-ориентированный – плавный, но медленно набирается. Гибридный – долго настраивается, сложно отлаживать, но лучше всего для пользователя.

Четвёртое семейство – нейронные 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 работает так, чтобы не оставаться на низком качестве, если сеть позволяет передавать больше данных.

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

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

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

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

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

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

Если бы плеер постоянно использовал битрейт 4000 кбит/с, за 600 секунд было бы загружено 4000 × 600 ÷ 8 = 300 000 килобайт, то есть 300 МБ. Ёмкость канала со скоростью 3,2 Мбит/с за те же 600 секунд составляет 3200 × 600 ÷ 8 = 240 000 килобайт, или 240 МБ. В результате плеер перебуферил бы 60 секунд – это 10% rebuffer ratio. Такой показатель неприемлем.

Если бы плеер поддерживал битрейт 2500 кбит/с, общий объём составил бы 187,5 МБ – это укладывается в лимит в 240 МБ. Падение скорости до 1 Мбит/с на 30 секунд приведёт к расходу буфера примерно на (2500 − 1000) × 30 ÷ 8 = 5625 килобайт. Если в начале провала в буфере было 30 с × 2500 кбит/с ÷ 8 = 9375 килобайт, то буфер остаётся в достаточном объёме и плеер продолжает работать без сбоев.

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

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

Гибридный плеер работал бы аналогично buffer-based, но с более плавными переключениями. Средний битрейт – около 2650 кбит/с. Количество переключений – около 2. Ребуферинг – 0.

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

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

ABR в VoD-стриминге имеет преимущество во времени: весь контент уже закодирован и упакован, поэтому плеер может свободно пробовать более высокие ступени качества – у сегментов нет дедлайнов. В случае с 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 Мбит/с, которую ни одна реальная сеть не тянет, – это ловушка для CDN-счёта: пара процентов зрителей быстро доберутся до неё, столкнутся с ребуферингом, и плеер вернёт их на более низкую ступень. Если менее 5% зрителей удерживают эту ступень – убирайте её.»

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

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

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

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

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

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

• ABR транслирует одно видео в нескольких битрейтах и позволяет плееру выбирать подходящий уровень в зависимости от текущей скорости сети.
• В любой ABR-системе выделяют четыре ключевых компонента: лесенка, пакетировщик, манифест и алгоритм. Понимание этих частей – основа; остальное уже детали.
• В продакшене используются три семейства алгоритмов: на основе пропускной способности (throughput-based), на основе буфера (buffer-based) и гибридные. Для пользователя предпочтительны гибридные.
• Оптимальное количество ступеней – от шести до девяти; шаг между соседними уровнями составляет примерно 1,5×.
• Бизнес-эффективность оценивается по пяти метрикам: время запуска, коэффициент повторной буферизации, средний битрейт, количество переключений в минуту, битрейт с учётом качества.
• Основные ошибки в продакшене – слишком мало ступеней, завышенная верхняя ступень и игнорирование измерения частоты переключений.

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

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

CTA

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