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

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

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

TL;DR

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

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

Стриминг невидим, пока работает, и неотлаживаем, когда ломается, потому что то, на что жалуется зритель («стрим завис»), почти никогда не находится там, где живёт настоящая проблема. Корень сбоя сидит на одной из девяти стадий между камерой и экраном, и вы не найдёте его без ментальной карты этих стадий. Мы писали статью для основателя, который сводит бюджет live-shopping, продакта, который спорит с вендором энкодеров, и инженера, который сделал плеер, но никогда не думал про 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 Mbps, сохранив максимум визуального качества. Стадия захвата задаёт верхнюю границу того, насколько хорошо стрим вообще может выглядеть, – никакая следующая стадия не выдумает деталей, которых датчик не зафиксировал.

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

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

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

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

Несколько кадров каждые пару секунд описываются целиком: это ключевые кадры (технически IDR в терминах H.264/HEVC, или 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 fps с H.264-энкодера при типичных 5 Mbps даёт:

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

Вклад энкодера в задержку – самый изменчивый в конвейере. Real-time энкодер на свежем GPU выдаёт результат за один интервал кадра – 16–33 мс – в однопроходном режиме. Высококачественный VOD-энкодер в многопроходном режиме считает секунды или минуты на кадр, что нормально для VOD и фатально для live. Пресеты вендоров с названиями 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, идёт в каждой версии любого энкодера, EOL у Adobe, но жив каждым OBS и Streamlabs. RTMP работает, но в нём нет нормального congestion control, нет UDP-пути и нет поддержки кодеков сверх H.264 + AAC. У нас есть отдельная статья про его статус в 2026.
• SRT (Secure Reliable Transport) – профессиональный стандарт контрибуции по публичному интернету. Определён в живом Internet-Draft IETF draft-sharabayko-srt-NN. На UDP, с настраиваемым forward error correction и automatic repeat request, поддерживает любые кодеки, и именно его сегодня используют большинство удалённых вещаний. Добавляет примерно 4 × RTT задержки как настраиваемый буфер восстановления потерь.
• WHIP (WebRTC-HTTP Ingest Protocol) – современный стандарт, IETF RFC 9725, опубликован в марте 2025. Тонкий HTTP-сигналинг поверх WebRTC для ингеста. Sub-second задержка, проходит через файрволы, идёт в каждом современном энкодере. Правильный дефолт для любого нового конвейера, начинающего работать в 2026, если нет конкретной причины не использовать его.

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

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

Практическое правило для бюджета полосы контрибуции: закладывайте 1.5 × кодированного битрейта самой высокой рендиции. Поток 5 Mbps требует устойчивого uplink 7,5 Mbps. Запас 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. Лестница из 5 ступеней до 1080p обычно потребляет 0,5–2 vCPU-эквивалента на поток, в зависимости от кодека и вендора. Транскодирование AV1 потребляет в 5–10 раз больше, чем H.264, при том же целевом качестве для кремния 2026 года – поэтому AV1-лестницы остаются редкостью в live и нормой в VOD.

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

Задержка транскодирования – второй по величине вклад во всём конвейере, после буфера плеера. Хорошо настроенный real-time транскодер добавляет 200–800 мс – работу одного сегмента – к общему glass-to-glass. Плохо настроенный (многопроходные настройки на 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, удваивая хранилище и усложняя cache key. 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, чтобы загнать glass-to-glass меньше 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-запросы и content negotiation. В крупном – кластер серверов с репликацией, мульти-регионом и just-in-time-упаковкой для менее популярных рендиций.

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

• Окна live-записи: сегменты 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 секунды), чтобы плеер видел новые сегменты; сами сегменты – длинный (часы), потому что они не меняются после записи.

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

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

Стадия 7 – CDN: shield, mid-tier, edge

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

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

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

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

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

Вклад CDN в задержку невелик на cache hit (10–50 мс) и большой на холодных промахах (100–500 мс, пока запрос идёт вверх по уровням и обратно). Для live первый зритель нового сегмента в каждом регионе платит цену холодного кэша; все следующие – ничего. Архитектуру разбираем в 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 Mbps, низкий джиттер, эпизодический bufferbloat при перегрузке.
• Мобильная (4G LTE, 5G mid-band, 5G mmWave) – обычно 5–300 Mbps, высокий джиттер, эпизодические полные потери при handover.
• Wi-Fi (Wi-Fi 6, Wi-Fi 7) – между модемом и устройством добавляет свои потери. Оптика 1,2 Gbps падает до 50 Mbps у устройства, если точка доступа за двумя стенами.
• Спутник (Starlink) – медианно 70–200 Mbps в развёртываниях 2025, RTT меньше 50 мс, но окнами 1–3 секунды при переключении спутников, которые segmented-стриминг переваривает, а real-time захлёбывается.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Захват: массив стадионных камер, выход по SDI в энкодерную.
• Кодирование: стадионный энкодер, H.265, GOP 2 с, однопроходный real-time.
• Контрибуция: SRT по выделенному 1 Gbps 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 Tbps в пик. Бюджет аварий тратится в основном на устойчивость энкодера и CDN; нога контрибуции короткая и прямая.

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы выпускаем стриминг и real-time-стеки с 2005 года – в видеоконференциях, OTT и интернет-ТВ, телемедицине, e-learning, видеонаблюдении и AR/VR. Девятистадийный конвейер из этой статьи – наша ежедневная работа: WHIP- и SRT-ингесты на стороне контрибуции для OTT live-событий; 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 дистрибуция: две стороны одного потока – следующая статья-компаньон, разрезающая конвейер на две половины.
• Семейное дерево протоколов доставки – когда у вас есть карта, семейное дерево протоколов показывает, какой протокол живёт на какой ноге.