ABR-алгоритмы на основе пропускной способности

TL;DR

ABR-алгоритмы, основанные на пропускной способности (throughput-based), выбирают следующий фрагмент видео следующим образом: они оценивают, с какой скоростью сеть передавала данные за последнее время, и выбирают максимально возможное качество, битрейт которого укладывается в эту оценку, делённую на небольшой запасной коэффициент. Математика сводится к одному делению и одному сравнению, поэтому это семейство алгоритмов доминировало в первые десять лет HTTP-стриминга и до сих пор остаётся значением по умолчанию в нативном плеере iOS и в hls.js. К 2026 году команды продолжают интересоваться этим подходом не из ностальгии: на стабильных сетях он действительно работает лучше, его проще отлаживать, и только его поведение можно предсказать теоретически. В статье подробно разбирается, как работает оценщик пропускной способности, рассматриваются три производственных варианта (rate-based, ELASTIC, PANDA), пять типичных мест, где он сбоит в реальных условиях, а также параметры настройки, которые превращают шумную реализацию в стабильную.

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

Throughput-основанный ABR – это алгоритм, который используется «по умолчанию», если явно не выбран другой. Нативный HLS-плеер Apple, open-source-библиотека hls.js (на которой работает большинство браузерных HLS-плееров вне Safari), ранние версии dash.js и почти все smart-TV-плееры, созданные до 2020 года, используют оценку пропускной способности как основной сигнал. Если вы запускаете стриминговый продукт, скорее всего, у вас уже сейчас работает throughput-основанный ABR – независимо от того, говорит ли об этом кто-то в команде. Понимание того, когда он выбирает правильную ступень качества, а когда – нет, позволяет отличить плавный и быстрый просмотр от опыта с постоянными скачками и буферизацией. Продакт, финансы и инженеры – все зависят от этого одного решения.

Идея одним абзацем

Представьте: вы только что скачали фрагмент видео, и он пришёл по сети за 1,6 секунды. Если в этом фрагменте было 4 мегабита данных, сеть передавала примерно 4 ÷ 1,6 = 2,5 мегабита в секунду в течение этой загрузки. Плеер запоминает это значение. Выбирая следующий фрагмент, он делает аналогичный расчёт для предыдущего и ещё более раннего, объединяя их в общую оценку: «насколько сейчас стабильна сеть?». Затем он обращается к лесенке битрейтов (bitrate ladder) – списку заранее закодированных версий видео разного качества – и выбирает максимальный битрейт, который остаётся «комфортно ниже» этой оценки. Именно на этой ступени плеер скачает следующий фрагмент. Весь алгоритм помещается в двадцать строк кода. Сложность заключается в том, что значит «комфортно ниже» и как корректно усреднять замеры, не реагируя панически на каждый кратковременный сбой.

Что делает алгоритм, шаг за шагом

Пройдём одну итерацию. Плеер только что скачал сегмент N. В его памяти хранится три факта: размер сегмента N в байтах, время скачивания в секундах и окно похожих замеров для сегментов N–1, N–2, N–3 и так далее.

Шаг 1 – посчитать пропускную способность за сегмент. Скачанные байты делим на прошедшие секунды и после перевода единиц получаем биты в секунду. По соглашению время измеряется от первого полученного байта до последнего, а не от момента отправки HTTP-запроса, потому что время отправки зависит от RTT, а не от пропускной способности. Некоторые реализации включают задержку в знаменатель, что делает оценку пессимистичнее; другие – исключают.

Шаг 2 – сгладить окно. Пропускная способность одного сегмента сильно колеблется. Wi-Fi может пропадать на десятки миллисекунд, когда сосед включит микроволновку; CDN-узел на периферии может временно выдать устаревшее соединение; фаза разгона TCP slow-start временно увеличивает пропускную способность стартового сегмента выше стабильного уровня. Чтобы отфильтровать шум, плеер объединяет последние K измерений в одно значение. Наиболее распространённый выбор – гармоническое среднее (harmonic mean), поскольку оно сильнее учитывает медленные замеры по сравнению с быстрыми – в отличие от арифметического среднего. Такая консервативность хорошо согласуется с асимметричной стоимостью ошибки: недооценить пропускную способность – значит потратить часть полосы пропускания; переоценить – привести к буферизации.

Гармоническое среднее трёх замеров: 3 ÷ (1/x₁ + 1/x₂ + 1/x₃). Для значений 2,8, 3,1 и 2,5 Мбит/с получаем 3 ÷ (1/2.8 + 1/3.1 + 1/2.5) ≈ 2.78 Mbps. Сравним с арифметическим средним – (2.8 + 3.1 + 2.5) ÷ 3 = 2.80 Mbps – и увидим, что гармоническое среднее смещается в сторону самого медленного замера. Чем больше разброс значений, тем заметнее этот разрыв.

Шаг 3 – применить запасной коэффициент. Деление сглаженной оценки на константу, превышающую единицу – обычно 1,2, 1,25 или 1,5 – даёт потолок: максимальный битрейт, который плеер может выбрать. Запасной коэффициент нужен потому, что оценка основана на среднем значении за недавнее время, а будущее поведение сети может отличаться. Коэффициент 1,25 означает: «беру ступень, использующую 80% от того, что сеть предоставила в прошлый раз».

Продолжая пример, 2,78 Мбит/с ÷ 1,25 = 2,22 Мбит/с. Это и есть предел.

Шаг 4 – выбрать максимальную ступень при битрейте ≤ потолок. Просканировать лесенку сверху вниз. Если лесенка 400, 750, 1500, 2500, 4000, 6000 kbps, максимальная ступень при битрейте ≤ 2,220 kbps – это 1,500 kbps. Именно её плеер и скачает следующей.

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

Это весь алгоритм. Он повторяется для каждого сегмента и каждого зрителя, без дополнительных входных данных.

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

Три продакшен-варианта

Разные реализации отличаются используемым окном замеров, применяемой функцией сглаживания и способом обработки старта. Три варианта составляют большую часть трафика в продакшене в 2026 году.

Вариант 1 – простой rate-based (дефолт hls.js)

Самый простой вариант: плеер хранит K последних сегментов – обычно 4 или 5 – в скользящем окне, вычисляет гармоническое среднее, делит его на запасной коэффициент 1.0 (да, по умолчанию 1.0 в hls.js) и выбирает ступень. Разработчики hls.js выбрали более низкий запасной коэффициент, исходя из того, что гармоническое среднее само по себе обеспечивает консервативную оценку; дополнительный консерватизм только недогружает сеть. В исходном коде hls.js файл src/utils/ewma-bandwidth-estimator.ts демонстрирует реальную реализацию, которая комбинирует пропускную способность за сегмент с экспоненциально взвешенным скользящим средним – сокращённо EWMA – чтобы при этом придавать больший вес более свежим измерениям внутри окна.

EWMA работает так: каждый новый замер обновляет оценку по формуле new = α × sample + (1 − α) × old, где α – число от 0 до 1, определяющее скорость забывания старых данных. При α = 0.5 вес каждого предыдущего замера уменьшается вдвое на каждом шаге. При α = 0.1 оценка почти не реагирует на отдельные замеры. hls.js запускает два EWMA-оценщика параллельно – быстрый и медленный – и использует меньшую оценку при решении о понижении качества, а большую – при решении о повышении.

Вариант 2 – ELASTIC

Опубликован в 2014 году De Cicco, Caldaralo, Palmisano и Mascolo как ELASTIC: A Client-Side Controller for Dynamic Adaptive Streaming over HTTP. Вариант использует оценку скорости с помощью PID-контроллера – системы обратной связи из теории управления. Вместо выбора качества по принципу «поделить и сравнить» ELASTIC задаёт целевой уровень буфера и передаёт ошибку между текущим и целевым значениями в контроллер, который плавно корректирует эффективный потолок. Преимущество перед обычным rate-based подходом – стабильность: при колебаниях сети около границы между двумя ступенями ELASTIC остаётся на нижней, не переключаясь на каждом сегменте. Недостаток – необходимость тонкой настройки: коэффициенты усиления PID требуют аккуратного подбора, а неудачные значения приводят к медленной, вялой реакции на реальные провалы в сети.

ELASTIC встречается в исследовательском коде и нескольких коммерческих продуктах; концептуально он является предком каждого «сглаженного оценщика пропускной способности с гистерезисом», который используется в современных плеерах.

Вариант 3 – PANDA

Опубликован в 2014 году Li, Begen, Erfanian и Houdaille как PANDA: Probe and Adapt for HTTP Video Streaming. PANDA был разработан для устранения конкретной проблемы стандартных rate-based ABR-алгоритмов: когда несколько плееров делят узкое звено канала, обычные оценщики пропускной способности приходят к состоянию, в котором каждый плеер ошибочно считает, что у него больше полосы пропускания, чем есть на самом деле, поскольку измерения «загрязняются» периодами простоя (OFF-время) между сегментами. PANDA вводит probing rate (зондирующую скорость), которая обновляется по закону управления независимо от фактической пропускной способности сегмента, и использует эту зондирующую скорость (а не измеренную пропускную способность) в качестве основы для выбора качества. В результате плееры ведут себя более «вежливо» при совместном использовании аплинка маршрутизатора, например, когда десять зрителей одновременно смотрят видео.

PANDA – эталонный алгоритм в академических сравнениях и интегрирован в несколько коммерческих ABR-решений на стороне CDN. Он не используется по умолчанию ни в одном из основных open-source-плееров, но ключевой урок, который он преподносит – «измеренная пропускная способность между сегментами» ≠ «доступная пропускная способность при скачивании сегмента» – теперь заложен в каждый серьёзный современный оценщик.

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

Условия: 30-минутное видео, шестиступенчатая лесенка (400, 750, 1500, 2500, 4000, 6000 kbps), сегменты по 4 секунды, зритель с стабильным соединением DSL на скорости 3,2 Мбит/с.

После первых трёх сегментов плеер зафиксировал пропускную способность 3,4, 2,9 и 3,0 Мбит/с (TCP slow-старт увеличил объём первого сегмента; второй и третий уже ближе к стационарному состоянию). Гармоническое среднее: 3 ÷ (1/3.4 + 1/2.9 + 1/3.0) ≈ 3.09 Mbps. С учётом запаса в 1,25 потолок составляет 2,47 Мбит/с. Максимальная ступень при битрейте ≤ 2 470 кбит/с – 1 500 кбит/с. Обратите внимание: это значение заметно ниже реальной скорости линии – и именно запасной коэффициент обеспечивает эту разницу.

Плеер скачивает сегмент 4 со скоростью 1,500 кбит/с. Четырёхсекундный сегмент объёмом 750 КБ загружается за 1,9 секунды при скорости линии 3,2 Мбит/с. Буфер увеличивается на (4 − 1.9) = 2.1 секунды. Измеренная пропускная способность для этого сегмента – около 3,16 Мбит/с, что близко к значению предыдущего окна. Гармоническое среднее почти не меняется; потолок тоже остаётся прежним – алгоритм снова выбирает битрейт 1,500 кбит/с.

Это счастливое место алгоритма. На стабильной сети ступень не меняется. Пользователь видит ровное качество, пока сеть не качается.

Теперь введём сбой на 10 секунд со скоростью 1,4 Мбит/с, начиная с 20-й секунды. Сегмент 6 (скачанный во время сбоя) обеспечивает 1,4 Мбит/с. Новое гармоническое среднее: 3 ÷ (1/3.0 + 1/3.16 + 1/1.4) ≈ 2.06 Mbps. Потолок – 1,65 Мбит/с. Максимальная ступень при битрейте ≤ – всё ещё 1500 кбит/с. Алгоритм остаётся на месте: защита гармонического среднего означает, что один плохой замер не приведёт к переключению ступени.

Но если сбой длится достаточно долго, чтобы два подряд идущих сегмента пришли со скоростью 1,4 Мбит/с, гармоническое среднее падает до 3 ÷ (1/3.0 + 1/1.4 + 1/1.4) ≈ 1.71 Mbps. Потолок – 1,37 Мбит/с. Максимальная ступень при битрейте ≤ 1 370 кбит/с – 750 кбит/с. Плеер понижает ступень.

Когда сеть восстанавливается, ситуация меняется в обратную сторону. После трёх последовательных сегментов со скоростью 3,2 Мбит/с гармоническое среднее снова достигает уровня 2,5+ Мбит/с, и плеер возвращается к битрейту 1500 кбит/с.

Эта симметрия – быстро снижать при устойчивых плохих замерах, медленно повышать при устойчивых хороших – и есть поведенческая подпись throughput-основанных ABR-алгоритмов. Buffer-основанные и гибридные подходы делают другие компромиссы; throughput-основанные – самое чистое выражение принципа «подстраивайся под сеть так, как она измеряется».

Когда throughput-based ABR – правильный выбор

Три формы развёртывания соответствуют сильным сторонам throughput-ориентированного ABR и компенсируют его недостатки.

Форма 1 – стабильные, предсказуемые сети. Офисный Wi-Fi, домашнее оптоволокно, спутниковая связь и большинство проводных подключений обеспечивают пропускную способность, которая меняется в масштабах секунд или минут, а не миллисекунд. Подход ABR на основе пропускной способности с оценкой «окно и среднее» отлично подходит для таких условий. Он подбирает оптимальную ступень качества за два-три сегмента и стабильно её удерживает.

Форма 2 – короткий контент. 30-секундное продуктовое видео не успевает «дожить» до завершения буферизации по алгоритму buffer-based. К тому моменту, когда этот алгоритм достигнет оптимальной скорости, видео уже закончится. В таких условиях выигрывает более быстрый разгон throughput-based ABR.

Форма 3 – плееры с ограниченными ресурсами. Встраиваемые set-top box, старые smart-TV и просмотрщики IoT-камер работают с ограниченной памятью и производительностью CPU. Алгоритму на основе пропускной способности достаточно запомнить последние 4–5 измерений и выполнить одно деление на сегмент. Алгоритм на основе буфера отслеживает непрерывную модель буфера и функцию полезности; гибридный вариант использует оба подхода. На процессоре 100 МГц и 2 МБ ОЗУ ABR на основе пропускной способности – единственный, который помещается.

Bitmovin Video Developer Report 2024 по-прежнему показывает, что примерно 40% опрошенных стриминговых инженеров используют throughput-based как основной алгоритм, а buffer-based и hybrid делят между собой оставшуюся долю. Эта доля постепенно снижается год от года – из-за роста популярности Shaka Player и dash.js, – но не падает резко – и это не случайно.

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

Где throughput-based ABR ломается

Пять режимов отказа объясняют почти каждую жалобу в продакшене на плеер, ориентированный на пропускную способность. У каждого из них есть решение.

Отказ 1 – нестабильный Wi-Fi. Пропускная способность домашнего Wi-Fi может меняться в 5–10 раз за секунду при активности других устройств. Чистый rate-based-оценщик реагирует на эти скачки и постоянно корректирует качество видео. Пользователь замечает, как картинка переключается между 720p и 1080p каждые 8 секунд. Фикс: увеличить EWMA α до 0.1 (более медленное забывание) или перейти на buffer-ориентированный алгоритм для сред с заведомо нестабильным соединением.

Отказ 2 – хендоверы мобильной сети. Когда телефон переключается с Wi-Fi на LTE или с LTE на 5G, пропускная способность может резко увеличиться в 5 раз или упасть в 5 раз за один сегмент. Гармоническое среднее не фиксирует эти скачки в течение двух-трёх сегментов. К моменту, когда алгоритм срабатывает, буфер уже опустошён. Фикс: объединить оценщик с жёстким нижним порогом (немедленно снижать качество до минимального уровня, если буфер меньше 2 секунд) и медленным восстановлением после стабилизации.

Отказ 3 – CMAF chunked transfer encoding. Когда энкодер использует Common Media Application Format (CMAF, ISO/IEC 23000-19) с chunked transfer, частичные сегменты поступают в плеер по мере их генерации – со скоростью, соответствующей битрейту текущего уровня, а не реальной пропускной способности сети. Наивный оценщик делит объём данных на время и делает вывод, что сеть работает так же быстро, как и текущий уровень. В результате плеер никогда не переходит на более высокий уровень, даже при линии 1 Гбит/с. Решение: измерять пропускную способность только во время пауз между чанками (когда сеть простаивает) или использовать метрику простоя HTTP-загрузчика. Это один из наиболее сложных багов в инженерии плееров с низкой задержкой, и он часто встречается в продакшене. Подробности по арифметике chunked transfer можно найти в статьях LL-HLS: подробный разбор и LL-DASH и CMAF chunked на практике.

Отказ 4 – несколько плееров на одном узком месте. Это и есть PANDA-отказ. Пять зрителей на одном домашнем маршрутизаторе получают примерно по 1/5 от пропускной способности аплинка, однако каждый замер плеера показывает, будто канал полностью принадлежит ему одному. Кумулятивная нагрузка на очередь маршрутизатора оказывается высокой, и все пять плееров начинают «подрагивать» синхронно. Фикс: использовать PANDA-стиль зондирования или координировать на уровне приложения (что на практике встречается редко).

Отказ 5 – первый сегмент. У плеера без истории воспроизведения нет точки отсчёта. Начать с низкой ступени – рисковать тем, что первые 5 секунд покажутся зрителю плохими (именно за это время он решает, продолжать ли смотреть). Выбрать слишком высокую – и плеер сразу начнёт буферизоваться. Решение: сохранять пропускную способность с предыдущей сессии и использовать консервативную среднюю ступень, если истории нет. Большинство современных плееров реализуют оба подхода.

Тюнинговые рычаги – действительно важные элементы

Если вы выпускаете плеер на основе пропускной способности и нужно его настроить, четыре параметра выполняют почти всю работу.

Ручка 1 – размер окна K. Сколько недавних замеров учитывает оценщик. При K = 3 реакция быстрая, но с колебаниями; при K = 8 – сглаженная, но медленная. По умолчанию: K = 5 для VoD, K = 3 для лайва.

Ручка 2 – запасной коэффициент. Делитель потолка. 1.0 (без запаса) – значение по умолчанию в hls.js, работает, потому что гармоническое среднее и так консервативно. 1.25 – наиболее распространённое «реальное» значение. 1.5 – для сетей, которым совершенно не доверяете (международные мобильные, низкоорбитальный спутник). Выше 2.0 – слишком большая нагрузка на полосу пропускания.

Ручка 3 – EWMA α. Имеет значение только при использовании экспоненциального сглаживания вместо фиксированного окна. Меньшее α (например, 0.1) означает более медленное забывание и стабильные оценки; большее α (например, 0.5) – более быстрое забывание и чувствительные оценки. Распространённый паттерн в продакшене: два параллельных EWMA с α = 0.1 (медленный) и α = 0.5 (быстрый), где медленный используется для решений о подъёме, а быстрый – для решений о дропе. Так работает hls.js.

Ручка 4 – гистерезис дропа. Определяет, требуется ли один плохой замер, два подряд или пересечение скользящего среднего, чтобы переключиться вниз. Один замер – реактивно; два – наиболее распространённый вариант; три – консервативно. Сопоставьте это с правилом нижнего порога буфера из «Отказ 2», чтобы устойчивый провал не вызвал буферизацию.

Таблица ниже показывает разумные значения по умолчанию для трёх типичных сценариев развёртывания.

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

Сравнение с альтернативами

Throughput-based – одно из четырёх семейств ABR. Компромиссы представлены в одной таблице.

Главная статья-пиллар ABR-стриминг: подробное объяснение рассматривает четыре семейства в контексте. Подход на основе пропускной способности – не «худший», а «правильный в трёх конкретных формах и неправильный за их пределами».

Типичные ошибки при шинге throughput-ориентированного плеера

«Ошибка 1 – доверие сегменту 1. TCP slow-start завышает измеренную пропускную способность первого сегмента в 2–3 раза. Исключите или снизьте вес сегмента 1 перед передачей в оценщик.»

«Ошибка 2 – не мерить переключения. Throughput-ориентированный плеер может переключаться между ступенями без буферизации, и ущерб для QoE остаётся незамеченным для метрики rebuffer ratio. Явно отслеживайте количество переключений в минуту. Если оно превышает одно за 60 секунд – алгоритм слишком реактивен.»

«Ошибка 3 – игнорировать буфер совсем. Чистый throughput-ориентированный подход начнёт буферизовать, если сеть падает быстрее, чем окно сглаживания. Правило «нижний порог буфера» (жёстко отбрасывать данные, если буфер < 2 с) – небольшое изменение, дающее значительный выигрыш в QoE.»

«Ошибка 4 – жёстко вшитые потолки. Ограничение алгоритма «не выше 4 Мбит/с для мобильных» выглядит разумно, пока вы не попробуете его на 5G-телефоне с линией в 500 Мбит/с. Используйте тип сети, определённый плеером, чтобы динамически менять лимиты, а не задавайте их жёстко.»

«Ошибка 5 – не разделять логику подъёма и дропа. Подъём и дроп имеют асимметричные цены: слишком быстрый подъём вызывает буферизацию; слишком медленный дроп – тоже; слишком медленный подъём тратит пропускную способность; слишком быстрый дроп выглядит плохо. Используйте два оценщика – быстрый для дропа и медленный для подъёма – вместо одного.»

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

Мы выпустили более 239 видео-продуктов с 2005 года и почти в каждой унаследованной кодовой базе встречали throughput-ориентированный ABR – обычно потому, что продукт начинал с hls.js или нативного iOS-плеера и никогда не пересматривал это решение. Большинство выигрышей достигается не за счёт замены алгоритма, а за счёт настройки его четырёх параметров под реальное распределение сетей зрителей. В e-learning мы оставляем throughput-ориентированный подход, потому что сеть стабильна, а стоимость буферизации высока; в mobile-first OTT добавляем правило нижнего порога буфера и учёт пропускной способности сессии; в телемедицине переходим на гибридный метод, поскольку клиническим экранам нельзя допускать падение качества во время диагностического процесса. Правильный алгоритм зависит от аудитории, а не от того, что сейчас популярно на конференциях.

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

• ABR на основе пропускной способности выбирает следующую ступень, сглаживая недавние скорости загрузки и деля их на запасной коэффициент.
• Это значение по умолчанию в hls.js, нативном плеере iOS и большинстве плееров для smart TV – скорее всего, вы пользуетесь им, даже не зная об этом.
• Почти вся настройка сводится к четырём параметрам: размеру окна, запасному коэффициенту, α для экспоненциального сглаживания (EWMA) и гистерезису снижения.
• Алгоритм хорошо работает на стабильных сетях, коротком контенте и в плеерах с ограниченными ресурсами; проигрывает на нестабильном Wi-Fi и при использовании CMAF с chunked transfer.
• Наиболее частая ошибка в продакшене – CMAF-чанк приходит ровно на границе битрейта ступени и не позволяет плееру перейти на более высокий уровень.
• Лучше всего сочетать throughput-based с жёстким правилом нижнего порога буфера, чтобы алгоритм не провоцировал буферизацию.

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

• ABR-стриминг: подробное объяснение без маркетинговых слов – статья-иллюстрация, в которой подход throughput-based рассматривается в сравнении с buffer-based, hybrid и neural ABR.
• LL-DASH и CMAF chunked на практике – разбор арифметики chunked transfer, которая сбивает с толку наивные оценщики.
• Наблюдаемость плеера и метрики продакшена – как реально измерить, работает ли ваш алгоритм так, как надо.

CTA

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