Конвейер стриминга от начала до конца

Опубликовано: 2026-05-20 · Время чтения: 21 мин · Автор: Николай Сапунов, CEO Фора Софт

Последняя сверка: 2026-05-20 по RFC 8216 (HLS, август 2017), Apple HLS Authoring Specification, ревизия 2025-09, ISO/IEC 23000-19:2024 (CMAF), ISO/IEC 23009-1:2022 (DASH), RFC 9725 (WHIP, март 2025), RFC 9000 (QUIC, май 2021), draft-ietf-pantos-hls-02 (апрель 2026) и DASH-IF Low-Latency Live Implementation Guidelines, ревизия 4.3.

TL;DR

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

Зачем это нужно

Стриминг незаметен, пока работает, и не поддаётся диагностике, когда ломается – ведь то, на что жалуется зритель («стрим завис»), почти никогда не совпадает с реальным местом сбоя. Корень проблемы скрывается на одной из девяти стадий между камерой и экраном, и найти его можно только с чёткой ментальной картой этих этапов. Мы писали эту статью для основателя, который сверяет бюджет live-шоппинга, для продакта, спорящего с поставщиком энкодеров, и для инженера, создавшего плеер, но никогда не задумывавшегося об origin shield. К концу вы сможете посмотреть на любой зависший, буферизующийся или лагающий стрим и назвать три наиболее вероятные стадии-виновницы в порядке приоритета с обоснованием. Это также ключевая статья всего нашего Learn-хаба: каждый последующий блок возвращается к той же карте и углубляется в одну из её частей.

Карта, к которой вы будете возвращаться

У живого стримингового конвейера девять стадий. Они следуют строго слева направо во времени: каждая стадия передаёт результат следующей, и проблема на стадии n всегда проявляется на стадии n + 1 и далее – никогда раньше. По порядку:

1. Захват (capture) – датчик и объектив преобразуют фотоны в сырые данные кадра.
2. Кодирование (encode) – энкодер сжимает сырые кадры в закодированный битовый поток.
3. Контрибуция / ингест – протокол передаёт битовый поток из точки съёмки в облако.
4. Транскодирование – облачный энкодер преобразует поток в несколько разрешений и битрейтов.
5. Упаковка (package) – битрейты упаковываются в сегменты и манифест, понятный плееру.
6. Ориджин (origin) – HTTP-хранилище для сегментов и манифеста.
7. CDN – shield, mid-tier, edge – многоуровневая кэш-иерархия, которая поглощает зрительский трафик, не перегружая ориджин.
8. Последняя миля – домашний Wi-Fi, сотовая сеть, спутниковый канал, по которым зритель получает поток.
9. Плеер (player) – приложение, которое загружает сегменты, декодирует кадры и отображает их на экране.

Каждый стриминговый сервис на планете – Netflix, Twitch, YouTube Live, ваш локальный OTT, корпоративный вебинар – использует одну и ту же девятиступенчатую архитектуру. Различия между ними заключаются в том, какие протоколы применяются на каждом этапе, насколько агрессивно настроены параметры задержки или стоимости и куда направляется бюджет на аварийное восстановление. Остальная часть статьи последовательно проходит все стадии, а в конце предлагает два разработанных примера: один и тот же конвейер, настроенный под две принципиально разные задачи.

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

Стадия 1 – Захват

Захват – это стадия, которую большинство представляет, услышав слово «стриминг», и при этом понимает хуже всего. Сенсор камеры – сетка крошечных светочувствительных элементов, которые мы называем пикселями, – преобразует свет в электрический сигнал тридцать, сорок, а иногда и шестьдесят раз в секунду. Этот сигнал считывается как сырой буфер кадра: двумерный массив пикселей объёмом несколько мегабайт, полностью несжатый. Кадр 1080p при 30 кадрах в секунду генерирует около 187 мегабайт в секунду сырых данных; кадр 4K на 60 fps – уже ближе к гигабайту в секунду.

Сырые данные стримить нельзя. Поток в 200 мегабайт в секунду полностью загружает домашнюю оптику, а гигабайт в секунду – небольшой офис. Задача всех последующих этапов – сократить этот «пожарный шланг» до объёма, который сможет принять канал зрителя, обычно 3–8 Мбит/с, сохранив при этом максимальное визуальное качество. Этап захвата определяет верхнюю границу качества стрима – никакие последующие этапы не смогут добавить деталей, которых не зафиксировал датчик.

Вклад захвата в задержку небольшой, но реальный: примерно один интервал кадра – то есть 16–33 мс при 30–60 fps – между моментом, когда фотон попадает на сенсор, и передачей буфера кадра энкодеру. Основные проблемы не связаны со стримингом – это плохой фокус, неправильная экспозиция, motion blur – но они проявляются позже как «стрим выглядит плохо», и выбор протокола здесь ничего не исправит.

Полезная аналогия: захват – это стенографист, который каждую секунду записывает каждое слово выступающего полным почерком. Запись точна и не поддаётся контролю. Каждая последующая стадия – это система сокращений, передающая смысл, не переписывая каждое слово.

Стадия 2 – Кодирование

Энкодер – первая стадия сжатия. Его задача – преобразовать исходный видеопоток в формат, пригодный для передачи по сети. Современные видеокодеки – H.264 (AVC), H.265 (HEVC), AV1, экспериментальный H.266 (VVC) – используют один и тот же приём: вместо описания каждого кадра с нуля они фиксируют, чем текущий кадр отличается от предыдущего. Большинство кадров в видео практически идентичны соседним, поэтому разница между ними невелика и кодируется небольшим количеством байт.

Несколько кадров, снятых с интервалом в пару секунд, описываются полностью – это ключевые кадры (в терминах H.264/HEVC – IDR, в более общем случае – IRAP). Между двумя ключевыми кадрами энкодер генерирует предсказанные кадры (P- и B-кадры), которые ссылаются на более ранние кадры в последовательности. Последовательность кадров между двумя ключевыми кадрами называется GOP (Group of Pictures), а её длина – интервал между ключевыми кадрами – является основным параметром настройки стриминга в энкодере.

Конвенция 2026 года – длина GOP составляет 2 секунды. Apple HLS Authoring Specification revision 2025-09 требует именно этого значения с 2018 года; DASH-IF Low-Latency Live (revision 4.3) придерживается той же нормы. Каждый крупный вендор энкодеров – AWS Elemental, Bitmovin, Wowza, NVIDIA – предлагает стриминговые пресеты с GOP по умолчанию в 2 секунды. GOP в 2 секунды означает ключевой кадр каждые 60 кадров при 30 fps, каждые 120 кадров при 60 fps, и служит чистой точкой разреза для следующей стадии (упаковки), на которой поток будет разделён на сегменты.

Математика вслух, впервые. Поток 1080p, 30 кадров в секунду, закодированный с помощью H.264-энкодера при типичной скорости 5 Мбит/с даёт:

• 5 000 000 бит/с ÷ 8 бит/байт = 625 000 байт/с = 625 КБ/с сжатого битстрима;
• 30 кадров/с × 2 с/GOP = 60 кадров на GOP;
• один ключевой и 59 предсказанных кадров на GOP;
• ключевой кадр в 5–10 раз тяжелее среднего предсказанного, поэтому типичный GOP весит около 1,25 МБ.

Вклад энкодера в задержку – самый изменчивый элемент в конвейере. Реалтайм-энкодер на современном GPU обрабатывает кадр за один временной интервал – 16–33 мс – в однопроходном режиме. Высококачественный VOD-энкодер в многопроходном режиме тратит на кадр секунды или даже минуты – это допустимо для VOD, но неприемлемо для трансляций в реальном времени. Именно поэтому на всех энкодерах существуют пресеты от вендоров с названиями low-latency, normal-latency, very-low-latency – они позволяют регулировать уровень задержки.

Типичная ошибка – задать GOP таким значением, с которым следующий упаковщик не сможет выровняться. Если длина сегмента 6 секунд, а GOP равен 5, каждый второй сегмент не содержит ключевого кадра, и плееру приходится брать предыдущий, чтобы начать декодирование. Держите GOP и длину сегмента согласованными – например, GOP 2 при сегментах по 2, 4 или 6 секунд – и весь конвейер будет работать стабильнее.

Стадия 3 – Контрибуция (ингест)

Контрибуция – это звено между энкодером и облаком. Это самый рискованный участок всего конвейера, потому что сеть между точкой съёмки и облаком обычно оказывается самым слабым звеном: одно домашнее соединение, 4G-точка, перегруженный Wi-Fi на турнире. Какой бы протокол ни передавал кодированный поток по этому участку, ему придётся справляться с джиттером, потерями и эпизодическими полными обрывами канала.

Три протокола доминируют в контрибуции 2026 года:

• RTMP (Real-Time Messaging Protocol) – устаревший стандарт, разработанный Adobe. Использует TCP, порт 1935, поддерживается во всех версиях энкодеров. Хотя Adobe объявила о прекращении поддержки (EOL), протокол продолжает работать благодаря таким инструментам, как OBS и Streamlabs. У RTMP нет полноценного управления перегрузками, отсутствует UDP-поддержка и поддержка кодеков за пределами H.264 + AAC. Подробности о его статусе в 2026 – в отдельной статье.
• SRT (Secure Reliable Transport) – профессиональный стандарт для передачи контента по публичному интернету. Определён в активном Internet-черновике IETF draft-sharabayko-srt-NN. Работает поверх UDP, поддерживает настраиваемую коррекцию ошибок и автоматическое повторное запросирование пакетов, совместим с любыми кодеками. Сегодня именно SRT используется в большинстве удалённых трансляций. Протокол добавляет задержку примерно в 4 × RTT за счёт буфера восстановления потерянных пакетов.
• WHIP (WebRTC-HTTP Ingest Protocol) – современный стандарт, закреплённый в IETF RFC 9725, опубликованном в марте 2025 года. Представляет собой тонкий HTTP-сигналинг поверх WebRTC для приёма потока. Обеспечивает задержку менее секунды, легко проходит через файрволы и поддерживается всеми современными энкодерами. Это оптимальный выбор по умолчанию для любого нового конвейера, запускаемого в 2026 году, если нет веских причин использовать что-то иное.

Два узких стандарта дополняют общую картину: RIST (SMPTE TR-06) – для контрибуции уровня вещания и ST 2110 / NDI – для студийных задач, где используется контролируемая гигабитная LAN. Полную картину мы разбираем в Выбор протокола ингеста в 2026.

Задержка передачи зависит от протокола. WHIP добавляет 100–500 мс. SRT использует настроенный буфер – обычно 1–4 секунды. RTMP добавляет задержку из-за хвостов TCP-переотправок, которая может составлять от 200 мс до 8 секунд в зависимости от потерь. Основные проблемы – обрыв канала (камера вышла из зоны Wi-Fi), исчерпание пропускной способности (uplink площадки перегружен) и переполнение буфера на энкодере (энкодер выдаёт данные быстрее, чем канал может их принять).

Практическое правило для бюджета полосы контрибуции: закладывайте 1,5 × кодированного битрейта самой высокой рендиции. Поток 5 Мбит/с требует устойчивого uplink 7,5 Мбит/с. Запас 50% компенсирует накладные расходы протокола, всплески при переотправке пакетов и периодические пики ключевых кадров.

Стадия 4 – Транскодирование

Транскодер – это облачный энкодер, который принимает единственный входящий поток и преобразует его в битрейтную лестницу – набор разрешений и битрейтов, из которого плеер выбирает подходящий вариант. Типичная лестница 2026 года для live-стриминга включает пять уровней: 1080p при 5 Mbps, 720p при 3 Mbps, 480p при 1,5 Mbps, 360p при 0,8 Mbps, 240p при 0,4 Mbps. Плеер выбирает уровень, соответствующий возможностям канала, и переключается каждые пару секунд при изменении условий.

Транскодирование – процесс затратный: каждая ступень представляет собой полное сжатие в формате H.264, HEVC или AV1 в реальном времени, выполняемое на GPU или специализированном ASIC. Лестница из пяти ступеней до 1080p обычно потребляет 0,5–2 vCPU-эквивалента на поток – в зависимости от кодека и производителя. Транскодирование AV1 требует в 5–10 раз больше ресурсов, чем H.264, при одинаковом целевом качестве на кремнии 2026 года – поэтому AV1-лестницы остаются редкостью в стриминге в реальном времени и нормой в VOD.

В транскодере принимаются два ключевых решения для продакшена. Первое – форма битрейтной лестницы: сколько ступеней, какие разрешения и битрейты – всё это описано в Построение битрейтной лестницы. Второе – выбор кодеков: каждая ступень лестницы должна быть закодирована во всех кодеках, которые способны декодировать устройства вашей аудитории. Типичный OTT-продукт 2026 года выпускает свою лестницу одновременно в H.264 (для универсальной совместимости) и либо в HEVC, либо в AV1 (для эффективности на поддерживаемых устройствах), что удваивает стоимость транскодирования.

Задержка транскодирования – второй по величине вклад в общий конвейер после буфера плеера. Хорошо настроенный real-time транскодер добавляет 200–800 мс – примерно время обработки одного сегмента – к общей задержке «от стекла до стекла». Плохо настроенный (например, с многопроходными параметрами на live-источнике) может увеличить задержку на 5–30 секунд – это самая частая причина жалоб: «почему мой live-стрим отстаёт на 30 секунд?»

Частая ошибка – использовать программное транскодирование на обычном CPU, когда доступен GPU или ASIC. NVIDIA NVENC, Intel Quick Sync и специализированные ASIC, такие как AMD Alveo MA35D, выполняют ту же задачу при энергопотреблении и задержке в 5–50 раз ниже. Если транскодирование дорого обходится, а требования к задержке жёсткие – это первое, куда стоит обратиться.

Стадия 5 – Упаковка

Упаковщик оборачивает транскодированные битстримы в формат, понятный сети и плееру. Он выполняет три задачи: разбивает битстрим каждой ступени на сегменты (короткие, независимо декодируемые фрагменты); формирует манифест, в котором перечислены сегменты и их битрейты; и размещает всё это на ориджин.

В 2026 году доминирующим форматом упаковки становится CMAF (Common Media Application Format, ISO/IEC 23000-19:2024). CMAF – это контейнер на основе фрагментированного MP4 (fMP4), разработанный так, чтобы один и тот же физический сегмент можно было использовать как для HLS, так и для DASH: один набор медиафайлов – два манифеста. До появления CMAF упаковка генерировала отдельные сегменты MPEG-TS для HLS и fMP4-сегменты для DASH, что удваивало объём хранилища и усложняло ключ кэширования. CMAF – это объединение этих подходов.

Упаковщик выдаёт:

• Для каждой ступени – последовательность медиа-сегментов: video_1080p_00001.m4s, video_1080p_00002.m4s, … – каждый длится 2–6 секунд и начинается с ключевого кадра.
• Манифест, в котором перечислены сегменты и рендеры. Для HLS это .m3u8-плейлист – текстовый файл с тегами #EXT-. Для DASH – .mpd, XML-документ. CMAF позволяет одному сегменту обслуживать оба манифеста.
• Init-сегмент на каждую ступень – init_1080p.mp4 – с конфигурацией кодека, скачивается один раз при запуске.

Длина сегмента – главный регулятор упаковщика. Сегмент в 6 секунд даёт меньше накладных расходов и лучше кэшируется, но при этом выше задержка. Сегмент в 2 секунды – стандарт для современных low-latency-конвейеров. CMAF-чанк длительностью 200 мс внутри 2-секундного сегмента – то, что используют LL-HLS и LL-DASH, чтобы добиться задержки от экрана до экрана менее 5 секунд без отказа от границ сегментов. Подробнее о сегментах и чанках – в LL-HLS подробно и LL-DASH и low-latency CMAF.

Вклад упаковщика в задержку при настройке low-latency CMAF невелик – 200–500 мс. При использовании классического HLS с 6-секундными сегментами он добавляет 6–18 секунд (одну–три длины сегмента, которые плеер должен накопить до старта). Поэтому «классический HLS» и «low-latency streaming» – это разные продукты, построенные на одном и том же упаковщике.

Типичная ошибка – выпустить манифест без тега EXT-X-INDEPENDENT-SEGMENTS, оставив плееру угадывать, декодируется ли каждый сегмент самостоятельно. Apple HLS Authoring Specification revision 2025-09 требует этот тег для LL-HLS; многие упаковщики по умолчанию отключают его.

Стадия 6 – Ориджин

Ориджин – это HTTP-сервер, который отдаёт манифест и сегменты любому, кто их запросит. В небольшом стриминговом продукте ориджин представляет собой одно бакетное хранилище (AWS S3, Google Cloud Storage, Backblaze B2) с тонким HTTP-слоем, обрабатывающим range-запросы и переговоры о содержимом. В крупном решении – это кластер серверов с репликацией, мультирегиональной поддержкой и упаковкой just-in-time для менее популярных рендиций.

Работа оригинала звучит просто – ответить GET-запросом на нужный сегмент, – а реализация уже нет. Продакшен-оригинал 2026 года тянет:

• Окна live-записи: сегменты прямого эфира действуют несколько минут; ориджин хранит скользящее окно из последних N сегментов, остальные удаляет – если только не включён DVR, тогда сохраняются часы.
• Just-in-time-упаковка: вместо предварительной упаковки каждой ступени в каждом протоколе мы храним исходный мезонин один раз и формируем манифесты по запросу. Экономия места в хранилище достигается за счёт дополнительной нагрузки на CPU.
• Подписанные URL: каждый URL сегмента содержит подписанный токен, по которому edge-сервер может отклонить запрос неавторизованного зрителя. Apple HLS, AWS CloudFront, Akamai EdgeAuth, Cloudflare Signed URLs – все используют один и тот же паттерн.
• Заголовки Cache-Control: манифесту устанавливается короткий Cache-Control (1–2 секунды), чтобы плеер оперативно видел новые сегменты; сами сегменты получают длинный TTL (часы), поскольку после записи они не изменяются.

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

Вклад ориджина в задержку в нормальном режиме невелик – время чтения сегмента из хранилища обычно составляет 20–100 мс – но резко возрастает, когда иерархия кэша нарушается и миллионы зрителей одновременно обращаются к ориджину. Именно для предотвращения таких ситуаций и существует следующая стадия.

Стадия 7 – CDN: защита, промежуточный уровень, крайняя точка

Content Delivery Network – это многоуровневая кэш-иерархия, которая поглощает зрительский спрос, не перегружая оригинальный сервер. Эта иерархия позволяла в 2007 году транслировать контент для 1000 зрителей, а в 2024 году – одновременно для 200 миллионов.

Современный CDN включает три-четыре уровня между зрителем и оригиналом:

• Edge – самый близкий к зрителю слой. У каждого крупного CDN в 2026 году насчитывается 300–600 точек присутствия на edge (PoP) в городах. Он отвечает на запросы зрителей напрямую: при попадании в кэш ответ приходит за 10–50 мс.
• Mid-tier – региональный кэш-слой, расположенный между edge и shield. Запросы, не найденные в edge, направляются сюда. У mid-tier больше объёма хранилища и более длительный срок хранения контента.
• Shield (origin shield) – единая региональная агрегирующая кэш-точка, стоящая между CDN и ориджином. Её задача – гарантировать, что ориджин получает всего один запрос на сегмент в регионе, независимо от количества edge, которые его запрашивают. AWS CloudFront называет эту технологию Origin Shield, Cloudflare – Tiered Cache, Google Media CDN – origin shield tier. Практика показывает: origin shield снижает нагрузку на ориджин на 90–95% во время прямых трансляций.

Типичный поток при cache miss: плеер зрителя обращается к edge → edge обращается к mid-tier → mid-tier обращается к shield → shield обращается к ориджин → ориджин возвращает сегмент → сегмент кэшируется в shield, mid-tier и edge по пути обратно к зрителю. Следующие 100 000 зрителей в том же регионе получают контент напрямую из edge; ориджин видит всего один запрос.

Арифметика, почему это важно. Live-стрим на 50 000 зрителей выдаёт 5 Mbps на каждого, итого 250 Гбит/с агрегированного egress. Если бы все зрители обращались напрямую к ориджину, ему потребовались бы 250 Гбит/с пропускной способности и соответствующие IOPS на хранилище. При правильно настроенном shield ориджин видит всего один запрос на сегмент в регионе – около 10 fetch’ов в секунду в 6 регионах, итого 50 Мбит/с egress на ориджине. CDN превращает проблему в 250 Гбит/с для ориджина в проблему в 50 Мбит/с.

Вклад CDN в задержку невелик при попадании в кэш (10–50 мс) и заметен при холодных промахах (100–500 мс, пока запрос проходит по уровням вверх и обратно). В случае стриминга первый зритель нового сегмента в каждом регионе платит за холодный кэш; все последующие – нет. Архитектуру мы разбираем в Origin shielding и tiered caching, а экономику – в CDN cost economics.

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

Самая дорогая авария CDN – рассинхронизация cache key, когда два зрителя запрашивают один и тот же сегмент, но CDN воспринимает их как разные запросы из-за различий в query string. Cache hit ratio падает с 95% до 5%, ориджин перегружается, стрим обрывается. Каждая команда по работе с CDN проходит этот урок один раз. Лечение – дисциплина канонических URL и аккуратная настройка cache key. Подробнее об этом в Cache keys для стриминга.

Стадия 8 – Последняя миля

Последняя миля – это участок от edge CDN до устройства зрителя: кабельный модем, оптический ONT, сотовый радиоинтерфейс, Wi-Fi-точка доступа. Это единственная стадия в цепочке, которой стриминговый инженер не может управлять. Именно здесь чаще всего возникают сбои – домашний интернет остаётся самым непредсказуемым звеном всей системы.

Последняя миля зрителя в 2026 году – это одно из:

• Фиксированная широкая полоса (DOCSIS-кабель, GPON-оптика) – обычно 50–1000 Мбит/с, низкий джиттер, эпизодический bufferbloat при перегрузке.
• Мобильная (4G LTE, 5G mid-band, 5G mmWave) – обычно 5–300 Мбит/с, высокий джиттер, эпизодические полные потери при handover.
• Wi-Fi (Wi-Fi 6, Wi-Fi 7) – между модемом и устройством возникают дополнительные потери. Оптика со скоростью 1,2 Гбит/с может падать до 50 Мбит/с у устройства, если точка доступа находится за двумя стенами.
• Спутник (Starlink) – медианная скорость 70–200 Мбит/с в развёртываниях 2025 года, RTT менее 50 мс, но с интервалами 1–3 секунды при переключении спутников. Такие окна выдерживает segmented-стриминг, но real-time трафик задыхается.

Вклад последней мили в задержку определяется RTT: 5–30 мс при фиксированной связи, 20–100 мс в мобильной сети, 30–60 мс у Starlink. Что касается пропускной способности – она зависит от того, сколько канал может передать в момент, когда плеер запрашивает данные. Подробно о сетевой реальности – в статье Полоса, throughput, джиттер, потери, а о реальной ситуации с последней милей – в Мобильный, спутник, 5G, Wi-Fi 6/7.

Что делает конвейер против «последней мили» – адаптивная битрейтная лестница. Плеер зрителя измеряет пропускную способность, показанную при последнем сегменте, и выбирает ступень лестницы, битрейт которой укладывается в эту пропускную способность. При падении пропускной способности плеер за одну выборку сегмента переходит на ступень ниже. Лестница – это защита конвейера от «последней мили» и причина, по которой зритель с мобильного соединения на 1,5 Mbps и зритель с оптической линией на 25 Mbps смотрят одно и то же live-событие через один и тот же CDN.

Стадия 9 – Плеер

Плеер – приложение на устройстве зрителя: вкладка браузера с hls.js, iOS-приложение, использующее AVPlayer, или встроенный WebKit на смарт-ТВ с Shaka – оно загружает сегменты, декодирует кадры и выводит их на экран. С точки зрения конвейера плеер – потребитель; с точки зрения пользователя – это всё.

Работа плеера состоит из пяти частей в следующем порядке:

1. Скачать манифест – получить .m3u8 или .mpd, проанализировать список рендиций и сегментов.
2. Выбрать стартовую рендицию – обычно самую низкую, чтобы воспроизведение началось быстро, а затем постепенно переходить на более качественные версии по мере заполнения буфера.
3. Набрать буфер – предварительно загрузить несколько сегментов и сохранить их в памяти. Спецификация Apple HLS Authoring требует, чтобы перед началом воспроизведения буфер содержал минимум 3 × длительность сегмента.
4. Декодировать – передать сегменты аппаратному декодеру платформы, получить необработанные кадры и отображать их с частотой обновления экрана.
5. Адаптировать – каждые несколько секунд измерять текущую пропускную способность и при необходимости переключаться на другую рендицию, если условия изменились.

Вклад плеера в задержку – самый значительный на всех стадиях классических HLS-конвейеров. Сегмент длиной 6 секунд с обязательным hold-back в 3 сегмента даёт минимальную задержку (glass-to-glass) в 18 секунд. При длине сегмента 2 секунды и hold-back в 3 сегмента задержка снижается до 6 секунд. Использование сегментов по 2 секунды с LL-HLS (CMAF-чанки по 200 мс, выборка частичных сегментов, блокирующие перезагрузки плейлиста) позволяет снизить задержку до 2–5 секунд. Конвейер на основе WebRTC, вообще не использующий сегменты, обеспечивает задержку 200–500 мс – ценой отказа от иерархии HTTP-кеширования.

Главные веб-плееры 2026 года – hls.js (5,8 млн загрузок в неделю, де-факто HLS-плеер для всех браузеров, кроме Safari, подробнее – в hls.js подробно), Shaka Player (от Google, используется внутри YouTube и во всех конвейерах, где нужны и DASH, и HLS, подробнее – в Shaka Player подробно) и dash.js (референсная реализация DASH). На устройствах Apple воспроизведение HLS происходит нативно через AVPlayer. У каждого смарт-ТВ – свой встроенный плеер; полную матрицу можно посмотреть в Плееры смарт-ТВ.

Типичная ошибка – оптимизировать энкодер, упаковщик и CDN под низкую задержку, но при этом использовать плеер со стандартными настройками. Хорошо настроенный hls.js способен снизить задержку LL-HLS-стриминга до менее чем одной секунды; в то время как «из коробки» hls.js на том же потоке даёт задержку около шести секунд. Плеер – это финальная стадия и самый значимый фактор воспринимаемой задержки.

Где всё это складывается: бюджет задержки

Соберите девять стадий вместе – и получите бюджет задержки «стекло к стеклу» – время между моментом, когда фотон попадает на сенсор камеры, и моментом, когда его изображение появляется на экране зрителя. Три числа стоит запомнить для 2026 года – из спецификации Apple, руководств DASH-IF и реальных продакшен-развёртываний:

Числа складываются по стадиям. Для low-latency HLS-конвейера типичная разбивка выглядит примерно так: захват – 30 мс, энкодер – 200 мс, WHIP-ингест – 400 мс, транскодер – 500 мс, упаковщик (CMAF-чанки) – 300 мс, CDN-фан-аут – 100 мс, последняя миля – 50 мс, буфер плеера – 2000 мс. Буфер плеера доминирует – обычно именно он и определяет задержку. Всё, что архитектор делает, чтобы снизить задержку ниже нескольких секунд, сводится к уменьшению этого буфера, чтобы стрим не прерывался. Подробный разбор бюджета см. в Latency, glass-to-glass.

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

Два разработанных примера

Конкретное лучше абстрактного. Два реальных конвейера – у обоих девять одинаковых стадий, но настроены они под разные задачи.

Пример A – OTT-событие в прямом эфире, 500 000 одновременных зрителей

Национальная футбольная лига транслирует матч в своём OTT-приложении. Цель glass-to-glass – 4–8 секунд (достаточно близко к эфирному ТВ, чтобы зритель приложения не получал спойлеры от соседа, смотрящего по кабелю). Аудитория: 500 000 человек одновременно в пиковые моменты, устройства – смешанные, в основном мобильные.

• Захват: массив стадионных камер, вывод по SDI в энкодер.
• Кодирование: стадионный энкодер, H.265, GOP 2 с, однопроходное кодирование в реальном времени.
• Контрибуция: SRT по выделенному каналу 1 Гбит/с point-to-point со стадиона в облако. Буфер 2 с на переотправку.
• Транскодирование: облачный транскодер, лестница из 6 ступеней (1080p / 720p / 480p / 360p / 240p / audio-only) в H.264 и HEVC.
• Упаковка: CMAF, сегменты по 2 с, чанки по 200 мс. HLS- и DASH-манифесты на одних и тех же медиафайлах.
• Ориджин: AWS S3 с окном хранения 4 часа для DVR.
• CDN: Akamai или Cloudflare с включённым Origin Shield. Edge POP – в каждом крупном городе страны.
• Последняя миля: мобильные сети, домашняя оптика, публичный Wi-Fi.
• Плеер: hls.js в браузерах, AVPlayer на iOS, ExoPlayer на Android, нативный плеер на смарт-ТВ.

Glass-to-glass: 4–6 секунд. Главный драйвер цены – CDN egress на 2,5 Тбит/с в пик. Бюджет аварий тратится в основном на устойчивость энкодера и CDN; путь контрибуции короткий и прямой.

Пример B – Телемедицинская консультация, 1 на 1

Пациент дома звонит врачу по видеосвязи через платформу телемедицины. Цель технологии glass-to-glass – задержка менее 400 мс (при большем значении разговор становится неестественным). Аудитория – один зритель с каждой стороны, полная дуплексная связь.

• Захват: камера ноутбука или телефона, сырые YUV-кадры.
• Кодирование: энкодер WebRTC, H.264 / VP9 / AV1 – выбор зависит от устройства; GOP 1 сек, однопроходное кодирование в реальном времени, поддержка simulcast или SVC для гибкого управления качеством.
• Контрибуция: соединение WebRTC peer-to-peer напрямую или через TURN-ретранслятор; стадии ингеста нет – энкодер подключается напрямую к SFU. NAT-обход обеспечивается через ICE, STUN и TURN.
• Транскодирование: как правило, не используется; SFU передаёт слои без пересжатия. Выбор нужного SVC-слоя происходит на стороне SFU вместо многоступенчатого транскодирования.
• Упаковка: отсутствует в классическом стриминговом понимании; кодированные кадры передаются в RTP-пакетах.
• Ориджин: сам SFU, размещённый в облаке и привязанный к региону для минимизации RTT между участниками.
• CDN: глобальная сеть SFU с медиа-серверами в каждом регионе; пациент и врач подключаются к ближайшему SFU.
• Последняя миля: те же Wi-Fi или мобильные сети, что и в примере A, но с более жёсткими требованиями к потерям и джиттеру.
• Плеер: используется WebRTC-стек в браузере или мобильном SDK – отдельное плеер-приложение не требуется.

Glass-to-glass: 200–400 мс. Главный фактор стоимости – вычислительная нагрузка на SFU, а не на egress. Бюджет аварийных ситуаций расходуется на оценку пропускной способности, FEC и переключение на TURN-ретрансляцию. Подробности по топологиям – в SFU vs MCU vs Mesh, по оценке пропускной способности – в WebRTC bandwidth estimation.

Те же девять стадий. Разные настройки, протоколы и структура цены. Форма конвейера – константа, выбор протоколов и параметров – переменная.

Типичные ошибки на всём конвейере

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

Обращаться с конвейером как с одним чёрным ящиком. Когда стрим лагает или зависает, хочется винить «стриминг». Правильный подход – пройти по конвейеру слева направо и выяснить, на какой стадии метрики ухудшились. Энкодер сообщает выходной битрейт и глубину очереди. CDN – hit ratio и объём исходящего трафика с origin. Плеер – состояние буфера и количество ребуферов. Та стадия, где показатели плохие, и требует исправления.

Оптимизировать одну стадию в изоляции. Купить быстрый энкодер не поможет, если плеер всё ещё буферизует 18 секунд. Переход на AV1 экономит трафик CDN, но сильно нагружает CPU транскодера. Каждая стадия взаимодействует с соседними; оптимизации без учёта общего бюджета часто лишь переносят проблему дальше по конвейеру.

Не выровнять ключевые кадры. Длина GOP в энкодере, длина сегмента в упаковщике и длина чанка в LL-HLS должны быть целыми кратными друг другу – иначе конвейер генерирует мусорный трафик и вызывает сталлы плеера. Комбинация GOP 2 с / сегмент 2 с / чанк 200 мс – конвенция именно потому, что арифметика получается чистой.

Игнорировать дефолты плеера. Все остальные этапы настраивают тщательно, а плеер оставляют с настройками по умолчанию от фреймворка. Плеер – последний и самый значительный источник задержек; его конфигурация – настройка уровня продакшена.

Считать бюджет по топ-рендиции. Большинство зрителей не будут смотреть вашу топ-рендицию – они выберут ту, что предложит канал, с учётом устройства. Рассчитывайте трафик CDN и объём хранилища оригинала исходя из реального распределения просмотров, а не по 4K-заголовку.

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

Мы занимаемся стримингом и real-time-стеками с 2005 года – в видеоконференциях, OTT и интернет-ТВ, телемедицине, e-learning, видеонаблюдении и AR/VR. Девятиступенчатый конвейер, описанный в этой статье, – наша повседневная практика: WHIP- и SRT-ингесты на стороне контрибуции для OTT-трансляций; ABR-лестницы транскодера и CMAF-упаковка для каталогного OTT; архитектура CDN и Origin Shield для поддержки миллионов зрителей одновременно; WebRTC-топологии на основе SFU для телемедицины и конференций. Каждый продукт мы тестируем на соответствие заявленному бюджету задержки в лаборатории до выхода в продакшн – потому что альтернатива – отлаживать ту же проблему в реальном времени на пике нагрузки.

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

• Конвейер стриминга состоит из девяти стадий: захват, кодирование, контрибуция, транскодирование, упаковка, ориджин, CDN, последняя миля и плеер.
• Длительность GOP, сегмента и чанка должны быть согласованы – конвенция 2026 года: 2 / 2 / 0,2 секунды.
• Origin Shield превращает проблему ориджина при миллионах зрителей в региональную задачу агрегации.
• Буфер плеера – главный источник задержки в любом HTTP-конвейере.
• WebRTC полностью устраняет буфер и сегментный слой; за это приходится платить архитектурой CDN.
• Оптимизируйте конвейер как единый бюджет: изолированные улучшения на одной стадии редко влияют на пользовательский опыт.

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

• Latency, glass-to-glass: что реально означают секунды – бюджет задержки, применяемый к каждой стадии, описанной в этой статье.
• Push vs pull, контрибуция vs дистрибуция: две стороны одного потока – сопутствующая статья, делящая конвейер на две части.
• Семейное дерево протоколов доставки – когда у вас есть карта, семейное дерево протоколов показывает, где именно используется каждый протокол.