Adaptive Bitrate Streaming (ABR): как это работает

TL;DR

Adaptive bitrate streaming – это механизм, при котором плеер самостоятельно выбирает, какую версию видео загружать, исходя из текущей скорости сети и состояния буфера. Сервер хранит одно и то же видео в нескольких разрешениях – от 240p при 200 Кбит/с до 4K при 15 Мбит/с, – а файл манифеста указывает плееру, где находится каждая версия. Алгоритм выбора качества (rate adaptation) – ключевая часть ABR; промышленный стандарт – гибридный подход, сочетающий измерение пропускной способности и уровень заполнения буфера. От правильно построенной битрейтной лестницы (encoding ladder) зависит как комфорт зрителя, так и расходы на CDN: разница между «хорошей» и «средней» лестницей у крупного OTT-сервиса может достигать 20–30% экономии трафика.

Зачем это знать

Эта статья – для продакт-менеджеров, основателей видеосервисов, CTO и инженеров, проектирующих стриминговые платформы: VOD, live, e-learning, телемедицина, OTT, прямые трансляции. Если вы выбираете между HLS и DASH, спорите с подрядчиком о структуре битрейтной лестницы, разбираетесь, почему пользователи жалуются на буферизацию, или пытаетесь понять, как Netflix отдаёт 4K при тех же 5 Mbps, что и у конкурентов – ABR как раз об этом. Без понимания того, как плеер принимает решения, любой разговор о качестве стрима превращается в гадание.

Что такое adaptive bitrate streaming

Представьте, что вы смотрите фильм в поезде. Сначала Wi-Fi на вокзале – отличный, потом туннель и 3G, затем – ничего, и снова 4G. Если бы у вас была только одна версия видео с битрейтом 5 Мбит/с, на 3G стриминг бы завис, а в туннеле – прервался. Adaptive bitrate streaming – технология доставки видео, при которой плеер автоматически меняет качество в реальном времени в зависимости от скорости сети и возможностей устройства – решает эту проблему так: видео хранится сразу в нескольких версиях, и плеер плавно переключается между ними, не прерывая воспроизведение.

Аналогия из жизни: представьте водопровод, к которому подключены трубы разного диаметра. Одна – тонкая (240p), другая – средняя (720p), третья – толстая (4K). К вашему крану в каждый момент времени подключена ровно одна труба. Если давление в магистрали падает, диспетчер незаметно переключает кран на трубу потоньше – вы продолжаете пить, просто из меньшей струи. ABR – это и есть тот самый диспетчер.

Технически каждое из этих качеств называется rendition (рендишн, вариант) или representation в терминологии DASH. Полный набор рендишнов одного видео – это и есть encoding ladder (битрейтная лестница): структурированный список «качество × разрешение × битрейт» – от самого слабого до самого высокого. Битрейт здесь – количество бит, используемых для кодирования одной секунды видео; подробнее об этом – в статье «Зачем сжимают видео: математика битрейта».

Когда вы открываете видео на YouTube или в Netflix и замечаете, как разрешение автоматически снижается с «1080p» до «720p» в тот момент, когда сосед запускает торренты, – вы наблюдаете работу ABR в чистом виде.

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

Зачем нужен ABR: что было до него

Чтобы понять, что именно изменил ABR, посмотрим, как доставляли видео раньше.

Эпоха progressive download (2003–2010). Браузер загружал MP4-файл целиком (или хотя бы первые секунды) и воспроизводил его по мере загрузки. Выбор качества отсутствовал – его определял автор файла. На быстром интернете всё работало отлично, на медленном – бесконечная буферизация и бесконечно крутившийся спиннер. Перемотка вперёд требовала ожидания, пока сервер достигнет нужной точки в файле.

Эпоха RTMP (Adobe Flash, 2005–2015). Появилась возможность переключать качество видео, но она была доступна только через закрытый протокол Adobe и требовала обязательного использования Flash-плеера. Работа была стабильной, однако всё оставалось в рамках экосистемы Adobe и зависело от постоянного TCP-соединения с медиа-сервером – каждый плеер поддерживал отдельное соединение, что серьёзно ограничивало масштабируемость.

Эпоха HTTP-стриминга (с 2009). Apple представила HTTP Live Streaming (HLS) для iPhone 3GS, вскоре за ней Microsoft выпустила Smooth Streaming, а Adobe – HDS. Все эти технологии решали одну и ту же задачу одним и тем же способом: видео разбивали на короткие сегменты длительностью 2–10 секунд, выкладывали в нескольких разрешениях на обычный веб-сервер и предоставляли плееру манифест-файл с описанием, где и что находится. К 2012 году MPEG утвердил открытый стандарт DASH (ISO/IEC 23009-1), и индустрия сконцентрировалась на двух протоколах: HLS (везде, особенно в экосистеме Apple) и DASH (везде, кроме Apple). Подробности о транспорте – в отдельной статье: «Стриминг-протоколы: 8 главных в 2026».

Главный сдвиг, сделавший ABR возможным: видео начали разбивать на маленькие фрагменты и передавать через обычный HTTP. Поскольку каждый фрагмент – это самостоятельный объект, его можно разместить в любой CDN, кэшировать как изображение и скачивать с любого сервера. А так как каждый фрагмент загружается отдельно, между ними можно легко переключать качество.

Анатомия ABR-системы: что на самом деле происходит

Любая ABR-система состоит из трёх компонентов: набора закодированных рендеров, манифеста и плеера. Рассмотрим каждый из них.

Шаг 1. Транскодирование в несколько рендеров

Исходный мастер-файл (обычно ProRes или mezzanine-кодек со скоростью 100+ Мбит/с) транскодируется в N выходных потоков. У типичного VOD-сервиса N составляет 6–8; у Netflix или YouTube – более двух десятков, поскольку они создают отдельные лестницы битрейтов под разные категории контента. Каждый рендеринг – это полноценное закодированное видео в H.264, H.265, VP9 или AV1.

Это «тяжёлая» часть. Кодирование 1080p H.264 в качестве VOD занимает около 2–3 минут CPU на минуту видео (при использовании софтверного x264 с настройкой medium), а полная лестница из 8 уровней – примерно 15–25 минут CPU на минуту контента. В случае с трансляцией арифметика меняется: кодирование должно выполняться быстрее реального времени, поэтому применяются аппаратные кодеры (NVIDIA NVENC, Intel Quick Sync, AMD VCN) или специализированные ASIC (например, NETINT Quadra) – подробнее об этом в статье про аппаратное ускорение.

Шаг 2. Сегментирование и упаковка

Каждый рендер нарезается на сегменты – короткие самодостаточные фрагменты, обычно длительностью 2–6 секунд. Слово «самодостаточный» здесь ключевое: каждый сегмент начинается с keyframe (I-кадра, то есть полного кадра, не зависящего от соседних), чтобы плеер мог начать декодирование с любого сегмента, не имея при этом предыдущих. Подробнее о структуре ключевых кадров – в статье про GOP-структуру.

Контейнер сегмента – fragmented MP4 (fMP4) в современных системах или MPEG-TS в старых HLS-цепочках. Если вы используете CMAF (Common Media Application Format, ISO/IEC 23000-19), то один и тот же набор fMP4-файлов подходит и для HLS, и для DASH – это позволяет сэкономить место в хранилище и в кэше CDN ровно вдвое. Подробнее – в «Контейнеры: MP4, fMP4, MKV, WebM».

Шаг 3. Манифест

Манифест – это текстовый файл, в котором перечислены все рендеры, указаны URL-адреса их сегментов, а также кодек и битрейт для каждого. Плеер сначала скачивает манифест и по нему узнаёт, какие варианты доступны.

В HLS манифест – это файл .m3u8 (текст в кодировке UTF-8):

#EXTM3U
#EXT-X-VERSION:7

#EXT-X-STREAM-INF:BANDWIDTH=300000,RESOLUTION=320x180,CODECS="avc1.42c01e,mp4a.40.2"
240p/playlist.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360,CODECS="avc1.4d401f,mp4a.40.2"
360p/playlist.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=2000000,RESOLUTION=1280x720,CODECS="avc1.640028,mp4a.40.2"
720p/playlist.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080,CODECS="avc1.640029,mp4a.40.2"
1080p/playlist.m3u8

Это «мастер-плейлист» – он перечисляет варианты. У каждого варианта есть свой playlist.m3u8, в котором уже содержится список конкретных сегментов:

#EXTM3U
#EXT-X-TARGETDURATION:6
#EXT-X-VERSION:7
#EXT-X-MEDIA-SEQUENCE:0

#EXTINF:6.000,
segment_000.m4s
#EXTINF:6.000,
segment_001.m4s
#EXTINF:6.000,
segment_002.m4s
...

В DASH манифест – это .mpd (Media Presentation Description), XML-документ, соответствующий стандарту ISO/IEC 23009-1:2022. Формат отличается, но идея та же: набор элементов Representation внутри AdaptationSet, каждый из которых имеет свои параметры – bandwidth, resolution, codec и URL-шаблон для сегментов.

Шаг 4. Плеер и алгоритм адаптации

Плеер – единственная сторона, принимающая решение. На сервере нет никакого «диспетчера», который бы переключал качество для клиента. Сервер просто отдаёт файлы, как обычный HTTP-сервер. Все интеллектуальные решения принимаются на стороне клиента.

Алгоритм работает в цикле:

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

Этот цикл – суть всей технологии. На нём держится весь user experience стриминга. Дальше – про то, как именно принимается решение в шаге 4.

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

Алгоритмы выбора качества: три семейства

За последние 15 лет академия и индустрия предложили десятки алгоритмов адаптации. Все они относятся к трём основным семействам.

Семейство 1. По пропускной способности (throughput-based)

Идея проста: измерить, с какой скоростью скачался предыдущий сегмент, и выбрать для следующего такой битрейт, чтобы он точно укладывался в доступную пропускную способность.

Формула в первом приближении:

estimated_bandwidth = segment_size_bits / download_time_seconds
target_bitrate = estimated_bandwidth × safety_factor

Где safety_factor обычно составляет 0.8–0.9: плеер выбирает качество чуть ниже максимально возможного, чтобы оставить запас на колебания сети.

Пример вживую. Скачали сегмент объёмом 3 МБ (24 миллиона бит) за 6 секунд:

estimated_bandwidth = 24_000_000 / 6 = 4_000_000 bps = 4 Mbps
target_bitrate = 4_000_000 × 0.85 = 3_400_000 bps ≈ 3.4 Mbps

В приведённом выше примере ближайший рендишн ≤ 3,4 Мбит/с – это 2 Мбит/с (720p). Выбираем его.

Проблема throughput-based подхода в чистом виде: пропускная способность мобильных и Wi-Fi-сетей сильно «шумит». Один сегмент скачивается за 6 секунд, следующий – за 2 (попал в окно с свободным каналом), третий – за 12 (сосед начал скачивать торрент). Если плеер просто следует за этими колебаниями, он будет прыгать между «720p → 1080p → 360p → 720p» каждые несколько секунд – а это хуже стабильного 720p, потому что для зрителя смена качества заметна и раздражает.

Поэтому реальные алгоритмы, основанные на пропускной способности, используют сглаженные средние: среднее гармоническое последних 5–10 сегментов или экспоненциально взвешенное среднее. Это устраняет скачки, но придаёт системе «инерцию»: плеер медленнее реагирует на изменения в сети.

Семейство 2. Buffer-based (по наполнению буфера)

Идея ещё проще: смотри не на сеть, а на буфер. Если буфер полон – например, скачано вперёд 30 секунд видео – можно позволить себе высокое качество и рискнуть медленным скачиванием. Если буфер пуст – наоборот, нужно срочно загружать самый лёгкий вариант, иначе зритель увидит спиннер.

Простейшая функция на основе буфера:

if buffer_seconds < 5:
    выбрать минимальный битрейт
elif buffer_seconds < 15:
    выбрать средний битрейт
else:
    выбрать максимальный битрейт

Канонический алгоритм этого семейства – BOLA (Buffer Occupancy-based Lyapunov Algorithm), опубликованный в 2016 году группой исследователей под руководством Кевина Спайтери (Spiteri et al., IEEE INFOCOM 2016). BOLA доказан как почти оптимальный с точки зрения теории управления (Lyapunov optimization – отсюда буква L в названии). Он используется по умолчанию в dash.js (референсный плеер MPEG-DASH) и в shaka-player от Google.

Главное преимущество buffer-based подхода – алгоритм совершенно не реагирует на кратковременные сетевые сбои: пока в буфере есть запас данных, ему всё равно. Главный недостаток – при старте воспроизведения буфер по определению пуст, поэтому BOLA в чистом виде начинает с минимального качества и медленно «разгоняется». Для VOD это допустимо, для live-стрима – катастрофа.

Семейство 3. Hybrid (гибрид)

В продакшене никто не использует чистый throughput или чистый buffer. Все современные плееры – гибридные.

Логика гибридного решателя:

• На старте, пока буфер мал – используй throughput, чтобы быстро подобрать подходящее качество.
• Когда буфер стабилизировался – переключайся на buffer-approach, чтобы не реагировать на каждый сетевой шум.
• Всегда применяй защитные правила: «не повышать качество более чем на один уровень за раз», «не снижать ниже минимума без двух подтверждений», «не возвращаться к высокому качеству раньше чем через 15 секунд после понижения».

Гибридные алгоритмы лежат в основе:

• dash.js / shaka-player – BOLA + правило пропускной способности (обе ABR-логики работают параллельно, выбирается более консервативное решение).
• hls.js – собственный гибридный алгоритм с оценкой пропускной способности на основе EWMA и буферным предохранителем.
• Netflix – закрытый внутренний алгоритм с компонентами машинного обучения (см. публикации Akhshabi, Begen, Dovrolis и др.).
• YouTube – гибридный алгоритм с целевым управлением качеством восприятия (QoE) и сильным учётом характеристик устройства.

В научной литературе встречаются и более экзотические подходы: MPC (Model Predictive Control, Yin et al., SIGCOMM 2015) – оптимизация по скользящему окну; Pensieve (Mao et al., SIGCOMM 2017) – RL-агент, обученный на симуляторе. Однако ни один из них в чистом виде не смог превзойти BOLA + throughput-гибрид в реальных условиях: прирост QoE составляет всего несколько процентов, а высокая вычислительная нагрузка и непредсказуемость поведения сводят на нет это преимущество.

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

Битрейтная лестница: как её правильно построить

Лестница – это набор пар «разрешение × битрейт», которые сервис хранит и раздаёт. Лестница – самая «продуктовая» часть всей ABR-инфраструктуры: от неё зависит и качество, и счёт за CDN, и время запуска воспроизведения.

Что в лестнице

Каждая ступень включает:

• Разрешение – например, 1920×1080.
• Битрейт – например, 4500 Кбит/с.
• Кодек и профиль – например, H.264 High Profile @ Level 4.0.
• Частота кадров – обычно совпадает с мастером (24/30/60 кадров в секунду), но на младших уровнях иногда снижается до 24 или 30 для экономии.
• Аудиоконфигурация – отдельный adaptation set, обычно AAC-LC 96–192 Кбит/с.

Сколько ступеней нужно

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

Промышленный консенсус 2026 года: 6–8 ступеней для H.264, 5–7 для HEVC/AV1. Современные кодеки более эффективны, поэтому для достижения той же визуальной плавности им требуется меньше промежуточных ступеней.

Классический фиксированный ladder (Apple HLS 2017 recommendations)

Это исторические данные от Apple для H.264. С тех пор кодеки стали эффективнее, а сети – шире; для HEVC/AV1 можно сократить битрейт на ~30–40% при сохранении того же визуального качества.

Персональная и сценическая лестница: куда движется индустрия

Фиксированная лестница плоха тем, что она универсальна. Но мультфильм «Простоквашино» и боевик «Джон Уик» при одинаковом разрешении 1080p требуют разного битрейта. Мультфильму – с его плоскими заливками и минимальным движением – хватает 1,5 Мбит/с для отличного качества; боевику же с динамичной камерой и шумом может не хватить и 8 Мбит/с.

Netflix в 2015 году первыми показали, что генерация per-title ladder – отдельной битрейтной лестницы для каждого видео – позволяет сэкономить 20–30% битрейта при сохранении той же визуальной метрики (VMAF). С тех пор этот подход стал стандартом для крупных OTT-платформ: Netflix, Amazon Prime, Disney+, YouTube; а также поддерживается в инструментах – AWS Elemental MediaConvert, Bitmovin Per-Title, Mux. Подробно эта тема рассмотрена в статье «Per-title и per-scene кодирование: умные битрейтные лестницы».

Convex hull: математика выбора пары «разрешение × битрейт»

При построении ladder возникает нетривиальный вопрос: на каком битрейте переключаться с 720p на 1080p? На 2,5 Мбит/с оба разрешения «работают», но какое будет выглядеть лучше? 1080p при 2,5 Мбит/с будет изобиловать артефактами – компрессия размывает детали; 720p при том же битрейте выглядит чище, но менее детализированным.

Ответ – построить выпуклую оболочку (convex hull) на графике «битрейт × VMAF» для всех разрешений и взять верхнюю границу. Каждая точка ladder должна лежать на этой границе. О VMAF и других объективных метриках качества – в «Метрики качества: PSNR, SSIM, VMAF».

Размер сегмента: главный компромисс

Длительность сегмента – параметр, который вы задаёте при упаковке. От него зависит почти всё:

Где здесь компромисс. Каждый сегмент должен начинаться с keyframe. Keyframe – это «полный» кадр, в 5–10 раз тяжелее обычного предсказанного. Чем короче сегменты – тем чаще keyframes – тем хуже эффективность кодирования. С другой стороны, чем короче сегменты – тем меньше латентность стрима, потому что плеер вынужден держать в буфере не менее 2–3 сегментов, чтобы обеспечить плавное воспроизведение. Длинные сегменты = задержка в 30–60 секунд; короткие сегменты = задержка 3–6 секунд, но дороже хранение и хуже кодирование.

Для классического VOD стандартное время сегмента – 4–6 секунд. В HLS для live-трансляций используется тот же интервал – 6 секунд. В low-latency стриминге применяются partial segments (LL-HLS) или chunked transfer encoding (CMAF-LL), которые позволяют делить сегмент на 10–20 микро-кусков длительностью 200–500 мс и начинать передачу до завершения кодирования всего сегмента. Подробнее – в «LL-HLS, WebRTC и CMAF-LL: гид по low-латентному стримингу 2026».

Буфер: что это и сколько его держать

Буфер плеера – это уже скачанные, но ещё не воспроизведённые сегменты. Если в данный момент воспроизведение идёт по T- секунде, а в буфере есть сегменты до T+15, значит, у плеера в запасе 15 секунд видео.

Зачем буфер вообще нужен. Сеть «дышит»: задержка скачивания сегмента может резко вырасти – с одной секунды до десяти. Если плеер не держит запас, любой такой скачок превращается в бесконечный спиннер. Буфер – это амортизатор.

Целевой размер буфера (target buffer):

• VOD без ограничений по live: 30–60 секунд. Чем больше – тем устойчивее к колебаниям сети, но тем больше требуется памяти на устройстве и тем хуже реактивность при смене качества (если изменился ladder, новые сегменты появятся только через минуту).
• Live HLS / DASH в стандартной задержке: 15–30 секунд.
• Low-latency LL-HLS / CMAF-LL: 2–6 секунд (это и есть та цена, которую вы платите за низкую задержку).
• WebRTC: 50–500 мс (буфер фактически отсутствует; всё зависит от jitter-буфера порядка десятков миллисекунд).

Минимальный буфер (safe buffer) – порог, при достижении которого плеер должен срочно начать «спасаться», переключившись на минимальное качество. Стандартное значение – 3–5 секунд.

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

QoE: как измерить, что ABR работает хорошо

QoE (Quality of Experience) – собирательный термин для того, насколько хорош реальный пользовательский опыт. У ABR-системы есть пять ключевых метрик QoE.

1. Время запуска (время до первого кадра)

Сколько секунд проходит от клика на «Play» до появления первого кадра? Промышленный стандарт: менее 2 секунд для VOD, менее 4 секунд для live. Каждая секунда сверх двух – это рост процента отказов на старте. По данным Akamai/Conviva за 2024–2025 годы, при времени запуска более 5 секунд вероятность, что зритель закроет стрим, превышает 25%.

2. Коэффициент повторного буферизирования

Процент времени, проведённого в буферизации (спиннер), от общего времени просмотра. Целевой показатель: менее 0,5% для VOD, менее 1% для live. Это самая «убийственная» метрика: каждый процент rebuffering снижает вовлечённость зрителей на ~2–3% (Conviva, 2024).

3. Средняя битрейт / Средняя качество видео

Сколько в среднем плеер показывал. Если у вас в ladder есть 5 Mbps, но плеер 90% времени крутил 800 Kbps – что-то не так либо с сетью пользователей, либо с алгоритмом.

4. Качество переключателей

Количество переключений качества на минуту просмотра. Слишком частые переключения (≥ 1 в минуту) раздражают зрителя – он замечает «дёргание». Оптимальный показатель – менее 0,3 переключений в минуту.

5. Время достижения наивысшего качества

Сколько секунд прошло от старта до момента, когда плеер достиг максимального доступного битрейта. Релевантно для VOD: если плеер «застрял» на 720p, хотя сеть позволяет 4K – алгоритм слишком осторожный.

Эти пять метрик следует измерять непрерывно – желательно с помощью сторонней QoE-платформы (Conviva, Mux Data, NPAW, Bitmovin Analytics) или собственной системы телеметрии.

Где ABR ломается: пять типичных проблем

Все системы, в которых мы участвовали, ломались в одних и тех же местах. Перечислим их.

Проблема 1. Lestnitsa без середины. Переход происходит сразу с 360p (500 Kbps) на 1080p (4500 Kbps). Между ними нужна промежуточная ступень – 720p (1500–2000 Kbps). Без неё плеер на средней скорости интернета будет либо «колбасить», либо зависать на 360p, не дотягивая до 1080p.

Проблема 2. Слишком толстая верхняя ступень. «Закатали» 1080p в 12 Mbps, чтобы был «бескомпромиссный bitrate». В реальности 99% пользователей никогда туда не доберутся, а CDN-биллинг страдает. Чёткий потолок 1080p H.264 – 5–6 Mbps; всё выше – деньги в воздух.

Проблема 3. Slow start. В первые 30 секунд плеер воспроизводит видео низкого качества, поскольку ещё не собраны данные о пропускной способности канала. Решение: использовать первый сегмент как пробный – заставить плеер загрузить сегмент среднего качества (720p) в первую очередь, чтобы быстрее оценить пропускную способность сети.

Проблема 4. Колебания на Wi-Fi. Пропускная способность домашнего Wi-Fi постоянно меняется от секунды к секунде. Алгоритм, использующий throughput без сглаживания, будет сильно «дергаться». Решение: применить сильное сглаживание (гармоническое среднее по ≥ 10 сегментам) или перейти на BOLA-подобный буферный алгоритм.

Проблема 5. Микро-стотерин при смене качества. Некоторые плееры при переключении качества инициализируют декодер заново, что вызывает паузу продолжительностью 50–200 мс. Решение: использовать одинаковые кодек и профиль на всех ступенях лестницы, а также совместимые SPS/PPS, чтобы избежать повторной инициализации декодера. В CMAF реализовать это проще, чем в legacy-формате MPEG-TS.

Где Фора Софт вписывается

В Фора Софт с 2005 года разрабатываем стриминговые платформы – от телемедицинских видеоконсультаций и e-learning до OTT и спортивных трансляций. Что касается ABR: мы проектируем encoding ladder с учётом бюджета CDN и реальной аудитории клиента – его геометра, типичных устройств и скорости интернет-соединения. Интегрируем готовые плееры (hls.js, shaka-player, JW Player, Bitmovin Player) и разрабатываем кастомные ABR-правила там, где стандартные алгоритмы не справляются – например, при адаптивном стриминге в условиях нестабильной связи на судах или в полевых условиях. Также помогаем настроить QoE-телеметрию и принимаем решение о переходе на per-title или per-scene encoding ladder.

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

• ABR – это набор закодированных в разных качествах рендеров, манифеста и алгоритма выбора качества на стороне плеера.
• HLS и DASH технически различаются, но концептуально схожи; CMAF позволяет упаковать оба формата в общий набор файлов.
• Промышленный стандарт алгоритма адаптации – гибрид throughput и buffer: чистый throughput слишком чувствителен к шуму, а чистый buffer медленно запускается.
• Битрейтная лестница из 6–8 ступеней – норма для H.264; использование per-title или per-scene ladder позволяет сэкономить 20–30% трафика.
• Размер сегмента – ключевой компромисс между задержкой, эффективностью кодирования и стоимостью CDN.
• Качество ABR-системы оценивается по QoE-метрикам: время запуска, доля ребуферинга, средний битрейт, количество переключений, время достижения максимального качества.

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

• Стриминг-протоколы: 8 главных в 2026
• Per-title и per-scene кодирование: умные битрейтные лестницы
• LL-HLS, WebRTC и CMAF-LL: гид по low-latency-стримингу 2026