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

TL;DR

Adaptive bitrate streaming – это механизм, при котором плеер сам выбирает, какую версию видео скачивать, исходя из текущей скорости сети и состояния буфера. Сервер хранит одно и то же видео в нескольких качествах (от 240p на 200 Kbps до 4K на 15 Mbps), а файл-манифест объясняет плееру, где какая версия лежит. Алгоритм выбора качества (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 Mbps, то на 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-streaming (с 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+ Mbps) транскодируется в N выходных потоков. У среднего VOD-сервиса N = 6–8; у Netflix или YouTube – больше двух десятков, потому что они генерируют отдельные ladder под разные классы контента. Каждый рендишн – это полноценное закодированное видео в H.264, H.265, VP9 или AV1.

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

Шаг 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 plain text):

#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

В ladder из примера выше ближайший рендишн ≤ 3.4 Mbps – это 2 Mbps (720p). Берём его.

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

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

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

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

Простейшая buffer-based функция:

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-based, чтобы не дёргаться на каждый сетевой шум.
• Всегда применяй защитные правила: «не подниматься больше чем на один уровень за раз», «не падать ниже минимума без двух подтверждений», «не возвращаться к высокому качеству раньше чем через 15 секунд после падения».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Per-title и per-scene ladder: куда движется индустрия

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

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 Mbps оба разрешения «работают», но какое будет лучше выглядеть? 1080p при 2.5 Mbps будет полно артефактов (компрессия размазала детали); 720p при том же битрейте – чище, но менее детализировано.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Startup time (время до первого кадра)

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

2. Rebuffering ratio

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

3. Average bitrate / Average video quality

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

4. Quality switches

Количество смен качества на минуту просмотра. Слишком много смен (≥ 1 в минуту) раздражает: зритель замечает «дёргание». Хороший таргет – < 0.3 смены в минуту.

5. Time to highest quality

Сколько секунд от старта до момента, когда плеер вышел на максимальный доступный битрейт. Релевантно для 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 секунд крутит низкое качество, потому что throughput-замеры ещё не собраны. Лечение: использовать первый сегмент как probe – попросить плеер скачать middle-tier (720p) первым, чтобы быстро получить оценку пропускной способности.

Проблема 4. Колебания на Wi-Fi. На домашнем Wi-Fi пропускная способность скачет каждую секунду. Throughput-алгоритм без сглаживания будет дёргаться. Лечение: сильное сглаживание (harmonic mean ≥ 10 сегментов) или переход на BOLA-подобный buffer-based.

Проблема 5. Микро-стотерин при смене качества. Некоторые плееры на смене рендишна делают decoder reinit, что вызывает 50–200 мс паузы. Лечение: использовать одинаковые кодек/профиль во всех ступенях ladder и совместимые SPS/PPS, чтобы decoder не пересоздавался. В 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 ladder.

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

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

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

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