Задержка видеотрансляции: что на самом деле означают эти секунды

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

Последняя сверка: 2026-05-20 со спецификациями RFC 8216, draft-ietf-pantos-hls-rfc8216bis-22 (май 2026), Apple HLS Authoring Specification (ревизия 2025-09), ISO/IEC 23009-1:2022, DASH-IF Restricted Timing Model (снимок от 24 октября 2024) и W3C WebRTC Candidate Recommendation.

TL;DR

Задержка видеотрансляции – это временной разрыв в секундах между моментом съёмки события камерой и моментом, когда зритель видит его на экране. В индустрии этот показатель называют glass-to-glass или end-to-end. Полная задержка складывается из нескольких этапов: буфер захвата, кодировщик, упаковщик, контрибьюшн-сеть, CDN, буфер плеера и обновление изображения на экране. Разные протоколы по-разному распределяют компромиссы внутри этой цепочки – поэтому классический HLS обеспечивает задержку 20–30 секунд, его low-latency-версии – 2–5 секунд, а WebRTC достигает 200–500 миллисекунд. В этой статье мы разбираем бюджет задержки по компонентам, приводим расчёты на конкретном примере, уточняем ключевые термины, которыми оперирует индустрия (и которые часто путают), и даём инструмент, позволяющий с первого взгляда оценить любое заявление вендора.

Почему это важно

Большинство решений в стриминговом продукте зависят от одного ключевого параметра – целевой задержки. Если инженерам ставят цель в 20 секунд, они используют классический HLS на любом CDN с минимальной стоимостью на зрителя. При задержке в 3 секунды – LL-HLS или LL-DASH с настроенным плеером и CDN, поддерживающим chunked-transfer. А при 500 миллисекундах – WebRTC со всеми сопутствующими затратами. Эта статья адресована в первую очередь умному, но нетехническому читателю – продуктовому менеджеру, проектирующему live-shopping-приложение, основателю, формулирующему задачу для инженеров, или оператору, изучающему презентацию вендора. При этом мы постарались сохранить точность фактов настолько, чтобы стриминг-инженер мог спокойно передать статью коллеге. К концу статьи вы сможете определить, за какими компонентами на самом деле скрываются конкретные цифры, и понять, какой протокол нужен для достижения заявленной целевой задержки.

Определение в одном предложении

Задержка стриминга – это время между моментом, когда кадр покидает объектив камеры, и моментом, когда он отображается на экране зрителя. Отраслевой жаргон называет это glass-to-glass, потому что путь начинается на одном стекле (линза камеры) и заканчивается на другом (стекло дисплея). Streaming Video Technology Alliance и Mux используют одно и то же определение; так же его трактуют Dolby OptiView, Cloudflare и инженеры Apple, написавшие HLS Authoring Specification.

Второй термин, с которым вы столкнётесь – end-to-end latency (сквозная задержка). В контексте стриминга это синоним. Иногда используют выражения capture-to-display или camera-to-screen – смысл остаётся тем же. В статье мы применяем термин glass-to-glass – он наиболее распространён и наименее двусмыслен.

Осторожно с маркетинговыми заявлениями. Вендоры часто называют задержкой что-то более узкое: protocol latency (только то, что добавляет плеер на стороне приёма), contribution latency (только путь от камеры до origin), first-mile latency (только путь от камеры до ingest). Ни одно из этих значений не равно glass-to-glass. Если в презентации написано: «наш протокол даёт 1,5 секунды» – без уточнений, безопаснее всего предположить, что измерили именно тот фрагмент, который выгоден продукту, а не то число, которое получит зритель.

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

Семь слагаемых бюджета

Glass-to-glass – это задача на сложение. Начинаем с камеры, заканчиваем экраном и суммируем время, которое каждый этап удерживает кадр. Имеет смысл выделить семь этапов. Диапазоны в таблице – реальные цифры из продакшена 2026 года по замерам Bitmovin, Mux, Wowza, Cloudflare и AWS Elemental; нижние и верхние границы мы рассмотрим для каждого слагаемого отдельно.

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

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

Захват и буферизация ingest (10 – 200 мс)

Камера не превращает свет в цифровой кадр мгновенно. Сенсору нужно время на экспозицию, ISP – на выполнение debayer и балансировку белого, устройству – записать результат в память, откуда его затем считывает кодировщик. Современная вещательная камера добавляет задержку 20–80 мс. Бытовая веб-камера или смартфон – 50–200 мс. Action-камера с компрессией прямо на сенсоре – менее 20 мс. Параллельно работает аудиопоток: даже если он отстаёт от видео на один кадр, начинаются проблемы с lip-sync – но это уже другая тема.

Кодировщик (50 – 400 мс)

Кодировщик преобразует исходное видео в сжатый битовый поток. Два модуля настройки определяют основную задержку.

Первый – lookahead: сколько кадров кодировщик анализирует вперёд перед принятием решения о текущем. Чем больше lookahead, тем выше качество при той же скорости, но растёт задержка. Типичный вещательный кодировщик использует 10–25 кадров lookahead, что при 30 fps добавляет 330–830 мс чистой задержки. Low-latency-профиль сокращает lookahead до 0–5 кадров и допускает небольшое снижение качества ради экономии сотен миллисекунд.

Второе – глубина B-кадров. B-кадры предсказываются как по предыдущим, так и по последующим кадрам, поэтому кодировщик не может выдать B-кадр, пока не получит будущий кадр. Структура GOP вида IBBPBBPBBP сама по себе добавляет задержку в два кадра. В профиле low-latency используется режим IPPP без B-кадров – это слагаемое исчезает.

Арифметика вслух: при 30 кадрах в секунду один кадр длится 33,3 мс. GOP IBBPBBP, задерживающий кодировщик на 2 кадра, добавляет 33,3 × 2 = 66,7 мс. Плюс 10 кадров lookahead – ещё 33,3 × 10 = 333 мс. Итого задержка кодировщика составляет около 400 мс.

Упаковщик (50 мс – 4 с)

Упаковщик берёт сжатый битстрим и разбивает его на единицы, которые ожидает протокол доставки: сегменты HLS или DASH длиной 2–10 секунд; чанки CMAF длительностью 200–500 мс; либо, в случае WebRTC, отдельные RTP-пакеты, которые в этом смысле вообще не «упаковываются».

Это самое крупное контролируемое слагаемое задержки – и именно из-за него инженеры спорят на проектировочных встречах. Классическая конфигурация HLS использует 6-секундные сегменты: упаковщик не может выдать сегмент, пока кодировщик не обработает шесть полных секунд видео. Такое решение добавляет до 6 секунд задержки ещё до того, как из упаковщика выйдет первый байт. LL-HLS (LL-HLS) и LL-DASH решают эту проблему переходом на partial segments (в HLS) или chunked CMAF (в DASH) длиной 200–500 мс: упаковщик отдаёт данные сразу после накопления чанка, а не полного сегмента. RFC 8216 (исходный HLS, опубликован в 2017 году) описывал только режим с полными сегментами; расширение для partial segments определено в Apple HLS Authoring Specification и в draft-pantos-hls-rfc8216bis-22 (май 2026) через EXT-X-PART-INF и PART-HOLD-BACK. ISO/IEC 23009-1:2022 (DASH) и DASH-IF Low-Latency Modes for DASH описывают аналогичный механизм chunked CMAF для MPEG-DASH.

У WebRTC в этом смысле вообще нет упаковщика. Каждый сжатый кадр разбивается на RTP-пакеты и сразу отправляется в сеть – границы сегмента отсутствуют, поэтому и сегментарной задержки нет. Именно поэтому WebRTC достигает субсекундных задержек, а HLS – нет.

Контрибьюшн-сеть (20 – 200 мс)

Контрибьюшн – это участок от кодировщика до origin-сервера. Его обеспечивают протоколы RTMP, SRT, RIST, WHIP и WebTransport, когда они передают поток от продюсера на стриминговую платформу. Подробно этот этап мы разбираем в статьях push vs pull, contribution vs distribution и отдельно по каждому ingest-протоколу. Что касается задержки, важно учитывать следующее: исправный контрибьюшн добавляет сетевой RTT и окно подтверждений протокола – обычно 50–150 мс при передаче через публичный интернет и меньше – на выделенной линии. SRT и RIST дополнительно накладывают регулируемое окно восстановления ошибок, обычно 50–250 мс.

CDN (20 – 200 мс)

Content delivery network – цепочка серверов, приближающая поток к каждому зрителю, – на удивление редко становится бутылочным горлышком. Хорошо настроенный CDN с origin shielding и многоуровневым кешированием добавляет 20–60 мс на «тёплом» edge и 100–200 мс при кеш-промахе. Гораздо большую проблему для CDN и задержек представляет не время распространения, а поддержка chunked transfer encoding. CDN, который не умеет передавать частичный HTTP-ответ плееру по мере поступления чанков с origin, не сможет отдавать LL-HLS и LL-DASH, какими бы быстрыми ни были его магистрали. Подробности – в статье CDN для стриминг-инженера.

Плеер-буфер (0,1 с – 30 с)

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

Классический HLS рекомендует буфер плеера объёмом в три сегмента. При длительности сегментов 6 секунд это составляет 18 секунд, при 4-секундных – 12. Управление этим параметром в спецификации Apple HLS Authoring Specification осуществляется через атрибут HOLD-BACK тега EXT-X-SERVER-CONTROL – по умолчанию он равен трём значениям target duration. В LL-HLS (LL-HLS) вместо этого используется PART-HOLD-BACK, который Apple определяет как «минимум двукратное и настоятельно рекомендуемое трёхкратное значение Part Target Duration» – то есть при чанках по 333 мс минимум 666 мс, желательно – 1 секунда. В DASH аналогичную функцию выполняет MPD@suggestedPresentationDelay; DASH-IF Restricted Timing Model (на основе версии от 24 октября 2024 года) определяет его как presentation delay, который «уменьшает time shift buffer, сдвигая его конечную точку в прошлое, и формирует effective time shift buffer меньшей продолжительности».

У WebRTC «плеер-буфер» – это не буфер в привычном смысле HLS, а джиттер-буфер: NetEQ для аудио и его видеоверсия для видео. Типичное значение – 50–200 мс, и в браузерах его можно настроить через RTCRtpReceiver.jitterBufferTarget из черновика W3C WebRTC-extensions. Это на два порядка меньше, чем плеер-буфер в HLS – вторая по важности причина, по которой WebRTC обеспечивает субсекундную задержку.

Декодер и экран (30 – 100 мс)

Декодер извлекает сжатые байты из плеер-буфера, распаковывает их в сырые кадры и помещает в очередь на вывод на экран. Аппаратные декодеры в телефонах или Smart TV добавляют задержку в 1–3 кадра конвейера; программные декодеры в браузере – ещё несколько миллисекунд. Сам экран отображает кадр с интервалом, соответствующим своей частоте обновления: 16,7 мс при 60 Гц, 8,3 мс при 120 Гц – и на потребительских телевизорах накладывает дополнительную задержку обработки панели, которую отключает режим game-Mode, но оставляет в movie-Mode. Итого для типичного телефона или ноутбука в 2026 году: 30–60 мс. Для Smart TV в режиме по умолчанию: 60–100 мс.

Разобранный пример: 25 секунд превращаются в 0,4

Возьмём конфигурацию и сложим семь слагаемых. Сначала классический HLS, затем WebRTC – для трансляции спорта в разрешении 1080p с стадиона в Лондоне до зрителя в Берлине.

Классический HLS, сегменты по 6 секунд:

Камера и ISP                  =      80 мс
Кодировщик, lookahead 10      =     333 мс
Упаковщик, 6-с сегмент        =   6 000 мс     ← ждёт один сегмент
Контрибьюшн (RTMP/SRT)        =     100 мс
CDN, тёплый edge              =      40 мс
Плеер-буфер, 3 × 6 с          =  18 000 мс     ← запас в три сегмента
Декодер + экран 60 Гц         =      50 мс
                              ──────────
Итого glass-to-glass          ≈ 24,6 с

WebRTC, jitter buffer по умолчанию:

Камера и ISP                  =     80 мс
Кодировщик, без lookahead     =    100 мс
Без упаковщика (RTP-пакеты)   =      0 мс
Контрибьюшн (RTP/SRTP)        =     80 мс
CDN: SFU forward              =     30 мс
Jitter buffer                 =    100 мс
Декодер + экран 60 Гц         =     30 мс
                              ──────────
Итого glass-to-glass          ≈ 0,42 с

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

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

Что на самом деле означает «low latency»

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

Снижение задержки – 5–10 секунд. Первая волна оптимизации HLS и DASH: короткие сегменты (2–4 с), небольшой буфер (2–3 сегмента), отсутствие lookahead в кодировщике. Достигается без смены протокола. Так в 2026 году работают большинство OTT-трансляций новостей и спорта в прямом эфире.

Low latency – 2–5 секунд. Режим chunked-HTTP и partial-segment: LL-HLS (Apple HLS Authoring Specification), LL-DASH (DASH-IF Low-Latency Modes), HESP. Требует CDN с поддержкой HTTP chunked transfer encoding до самого плеера, origin-сервера, выдающего partial segments, и плеера, способного с ними работать. Так реализована «низкая задержка» в Twitch, в стеке Mux и в большинстве live-беттинга и live-шоппинга в 2026 году.

Ultra-low / real-time – задержка менее одной секунды. Режим WebRTC, плюс передача медиа через QUIC (на май 2026 года технология ещё находится в draft-ietf-moq-transport-NN), плюс HESP у некоторых операторов. Реальная задержка отличается от просто низкой задержки качественно: зритель может ответить, кликнуть, проголосовать, сделать ставку – всё это в режиме, соответствующем тому, что он видит. Стоимость на одного зрителя также существенно выше – обычно в 2–10 раз дороже за минуту по сравнению с LL-HLS при той же аудитории.

«Частая ловушка. Вендоры любят указывать нижнюю границу задержки, которую их стек теоретически может обеспечить, а не ту, с которой реально работают их клиенты. У Twitch «Low Latency» – это 2–5 секунды с точки зрения приёмника, но RTMP-канал стримера добавляет ещё 2–5 секунд, и итоговая задержка от экрана до экрана (glass-to-glass) для зрителя в чате составляет около 7 секунд. Читая цифры, всегда уточняйте, какие этапы они охватывают.»

Как измерить это число

Невозможно настроить то, что нельзя измерить. Существует четыре метода – от простого и неточного до сложного и строгого.

Метод секундомера в кадре. Направьте камеру на смартфон с миллисекундным секундомером. Сделайте один снимок, на котором одновременно видны сам смартфон (на переднем плане) и монитор с транслируемой картинкой с этого же устройства (на заднем плане). Разница во времени между показаниями на снимке – это glass-to-glass задержка. Быстро, дёшево, точность около одного кадра за один замер. Но не репрезентативно – это всего один сэмпл.

Метод вшитого таймкода. Продюсер «вписывает» SMPTE-таймкод (или монотонный счётчик в виде цифр) в верхний левый угол каждого кадра. На приёмной стороне распознаётся таймкод, считанный с экрана, и сравнивается с текущим временем по часам. Метод воспроизводим, скриптуем, точность – один кадр.

Метод LED + фотодетектора. Перед линзой пульсирует светодиод, а фотодетектор прикреплён к экрану приёмника. Осциллограф фиксирует фронты сигнала с обеих сторон и измеряет разницу во времени. Точность – в микросекундах; именно так работают RidgeRun и производители FPV-устройств. Для стримингового продукта это избыточно, но иногда требуется по условиям контракта.

Внедрение Producer Reference Time (prft). В HLS- и DASH-стеках кодировщик может вставлять в каждый CMAF-чанк бокс ISO/IEC 14496-12 prft, а плеер сравнивает его со своим временем при отрисовке. DASH-IF Low-Latency Modes рекомендует именно этот подход для продакшен-телеметрии. Непрерывно, автоматически – и именно так Mux Data и Conviva строят графики задержки по сессиям.

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

Задержка и три похожие вещи, с которыми её путают

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

Start-uptime – время от нажатия кнопки «Play» до появления первого кадра. Это не то же самое, что задержка. Поток может иметь glass-to-glass задержку 25 секунд при старте за 2 секунды (DASH и HLS), а может – glass-to-glass задержку 0,4 секунды при старте за 4 секунды (WebRTC, пока согласовываются ICE-кандидаты). Эти два показателя меняются независимо друг от друга; оба важны для зрителя, но по разным причинам. Подробности – в статье QoE-метрики стриминга.

Rebuffer ratio – это доля общего времени просмотра, проведённая в ожидании загрузки (в «спиннере»). Такая ситуация возникает, когда буфер плеера оказывается слишком коротким для текущих сетевых условий. Сокращение задержки без улучшения bitrate-лестницы почти всегда приводит к росту rebuffer ratio: эти два показателя связаны между собой, как точки на одной кривой, а не как параметры на независимом ползунке. Вендор, который заявляет о низкой задержке, но не указывает rebuffer ratio, рассказывает лишь половину истории.

Jitter – разброс времени между приходом соседних пакетов. Высокий джиттер вынуждает плеер увеличивать буфер, что приводит к задержке. То есть джиттер – это вход в бюджет задержки, а не её синоним. Подробно – в статье пропускная способность, throughput, jitter, потери пакетов: сетевая реальность.

Таблица задержек протоколов 2026

Если из статьи вы запомните только одну вещь – пусть это будет эта таблица. Здесь приведены нижние и типичные значения glass-to-glass для каждого протокольного семейства, а также условия, при которых их можно достичь.

Три полезных наблюдения. Во-первых, каждый протокол с нижней границей выше секунды компенсирует её не недостатками инженерии, а запасом плеер-буфера. Во-вторых, типичный диапазон всегда в 1,5–3 раза выше нижнего – это и есть реальный продакшен, а нижняя цифра – лабораторное демо. В-третьих, Media over QUIC – первый с момента появления WebRTC протокол, который изначально проектируется так, чтобы нижняя и типичная границы совпали; подробности – в статье Media over QUIC.

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

С 2005 года мы разрабатываем live- и near-live-видео для клиентов в OTT, live-коммерции, телемедицине, e-learning, видеонаблюдении и AR/VR. Задержка – это первое ограничение, с которым борются наши стриминг-инженеры: мы внедряли LL-HLS-стек для OTT-операторов с chunked-CMAF origin и настроенными плеерами hls.js / Shaka; WebRTC-стек для телемедицины и live-шоппинга на SFU mediasoup и LiveKit; SRT- и RIST-каналы для вещательных партнёров. Бюджет задержки в каждом проекте – это письменный документ, охватывающий все этапы: захват, кодирование, упаковку, контрибьюшн, CDN, воспроизведение, декодирование – с чётко заданным показателем glass-to-glass и обязательной проверкой на staging перед запуском.

Главное

• Glass-to-glass – это время от линзы камеры до экрана зрителя; единственное значение задержки, которое реально ощущает зритель.
• Полная задержка складывается из семи компонентов; плеер-буфер почти всегда является самым значительным из них.
• Классический HLS – 20–30 с; LL-HLS и LL-DASH – 2–5 с; WebRTC – 0,2–0,8 с.
• Упаковщик и плеер-буфер определяются выбором протокола, а не ограничениями технологий.
• Существует три уровня «low»: reduced (5–10 с), low (2–5 с), real-time (<1 с) – каждый требует своего технологического стека.
• Для работы с продуктом измеряйте задержку с помощью встроенного таймкода; для телеметрии в продакшене используйте внедрение prft.

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

• Live, VOD и near-live: три задачи, которые выглядят одинаково, но решаются по-разному
• Пропускная способность, throughput, jitter и потери пакетов: сетевая реальность
• HLS подробно: m3u8, сегменты, multi-variant-плейлисты