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

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

Последняя сверка: 2026-05-20 со спецификациями RFC 8216, draft-pantos-hls-rfc8216bis-22 (май 2026), Apple HLS Authoring Specification revision 2025-09, ISO/IEC 23009-1:2022, DASH-IF Restricted Timing Model snapshot 2024-10-24 и 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; нижние и верхние границы мы разберём по каждому слагаемому отдельно.

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

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

Захват и буфер 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 fps один кадр – это 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-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 с)

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

Классический HLS рекомендует плеер-буфер в три сегмента. При сегментах по 6 секунд это 18 секунд. При 4-секундных – 12. Apple HLS Authoring Specification управляет этим через атрибут HOLD-BACK тега EXT-X-SERVER-CONTROL – по умолчанию три target duration. 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, а jitter buffer: 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 с тремя разными значениями нижней границы. Понимать, что имеет в виду конкретный вендор, – разница между рабочей презентацией и потерянным кварталом.

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

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

Ultra-low / real-time – меньше 1 секунды. Режим WebRTC, плюс Media over QUIC (на момент мая 2026 ещё в draft-ietf-moq-transport-NN), плюс HESP у некоторых операторов. Real-time-задержка качественно отличается от просто low latency: зритель может ответить, кликнуть, проголосовать, сделать ставку на то, что видит. Стоимость на зрителя тоже качественно другая – обычно в 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 строят графики per-session-задержки.

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

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

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

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

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

Jitter – разброс времени между приходом соседних пакетов. Высокий jitter заставляет плеер держать больший буфер, что стоит задержки. То есть 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-shopping на 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-плейлисты