Задержка WebRTC-трансляции меньше секунды: как мы вывели 10 000 зрителей на 0,4–0,5 с

Обновлено в ноябре 2026: бюджет задержки по этапам, каскад SFU, цены доставки на ноябрь 2026, настройки WebRTC, WHIP/WHEP/MoQ, оценка доработки с ИИ-инструментами и схемы.

Задержка WebRTC-трансляции меньше секунды складывается из трёх вещей: WebRTC на всём пути от сцены до зрителя, каскада медиасерверов (SFU), который раздаёт поток тысячам людей, и настроек кодирования и буфера, которые не дают задержке расти, когда сеть шумит. Так мы построили Worldcast Live: 0,4–0,5 секунды от камеры до экрана при 10 000 зрителей одновременно.

Ниже разбираем, куда уходят миллисекунды, как устроен каскад, какие настройки мы меняли, сколько стоит доставка в ноябре 2026 года и когда задержка больше секунды выгоднее. Общий обзор протоколов и российских CDN для стриминга с низкой задержкой — в нашем руководстве по стримингу с низкой задержкой; здесь фокус на WebRTC и на практике одного проекта.

Задержка WebRTC меньше секунды: короткий ответ

Чтобы трансляция на тысячи зрителей шла быстрее секунды, нужны пять решений.

1. WebRTC от источника до зрителя. HLS и даже LL-HLS держат буфер в несколько секунд, поэтому быстрее 2 секунд не работают.
2. SFU вместо P2P. Медиасервер принимает один поток и пересылает его зрителям без перекодирования.
3. Каскад узлов. Главный SFU плюс edge-узлы, каждый на несколько сотен зрителей; узлы добавляются по мере роста аудитории.
4. Настройки под низкую задержку. Без B-кадров, короткий интервал ключевых кадров, simulcast из трёх слоёв, джиттер-буфер по типу контента.
5. Измерение. Задержку от камеры до экрана замеряют на каждом релизе, иначе она незаметно расползается.

Почему этот разбор пишет Фора Софт

Фора Софт делает видео- и real-time-продукты с 2005 года: больше 250 сданных проектов, около 50 инженеров. Трансляции с задержкой меньше секунды мы строили для концертов, трейдинга и онлайн-обучения. Первая версия этой статьи вышла в 2021 году по следам Worldcast Live; в ноябре 2026 года мы обновили цифры, цены и стек.

Если вы планируете прямые эфиры с интерактивом, эту работу закрывает наша разработка видеостриминга и WebRTC-трансляций: от выбора медиасервера и каскада до плеера, записи и монетизации.

Что такое задержка «от камеры до экрана»

Задержка от камеры до экрана (glass-to-glass) — время между моментом, когда камера сняла кадр, и моментом, когда зритель увидел его на экране. Её не путают с пингом: пинг показывает только сетевую часть, а зрителю важна сумма всех этапов.

Для видеозвонка норма — до 300–400 мс, иначе собеседники перебивают друг друга. Для односторонней трансляции на большую аудиторию привычны и 5, и 30 секунд: так работает классический HLS. Граница интерактива — одна секунда: ниже неё чат, ставки и вопросы ведущему ощущаются живыми.

Рисунок 1. Задержка протоколов доставки от камеры до экрана: меньше секунды дают только WebRTC и MoQ.

Куда уходят миллисекунды: бюджет задержки по этапам

Задержку удобно считать как бюджет в 1000 мс, который делят пять этапов. Таблица показывает разбивку, от которой мы отталкиваемся при проектировании интерактивной трансляции 720p.

Источник: расчёты Фора Софт по проектам, ноябрь 2026; ориентиры по LL-HLS — документация Apple и Mux.

Арифметика объясняет, почему LL-HLS не опускается ниже секунды: плееру нужно накопить несколько частичных сегментов, и один этот буфер больше всего бюджета WebRTC. Подробно протоколы сравнили в статье WebRTC или HLS: какой протокол выбрать.

Когда трансляции нужна задержка меньше секунды

Меньше секунды нужно там, где зритель на что-то реагирует в реальном времени или сравнивает картинку с другим источником.

• Спорт и ставки. Соседи кричат «Гол!», а у зрителя мяч ещё в центре поля. Для ставок по ходу игры задержка больше секунды делает продукт невозможным.
• Онлайн-аукционы и торги. Ставка должна дойти до аукциониста до удара молотка.
• Интервью и эфиры с вопросами. Задержки ведущего и гостя складываются; на 5 секундах диалог разваливается.
• Концерты с общением. В Worldcast Live зрители и музыканты общаются через видеочат, а плеер встроен на разные сайты: двое друзей на разных сайтах должны слышать один и тот же такт.
• Трейдинг и обучение. Трейдеры повторяют действия ведущего, ученики задают вопросы преподавателю.

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

Почему HLS не даёт меньше секунды, а WebRTC даёт

HLS и DASH режут поток на сегменты и раздают их через обычный HTTP-кэш CDN. Это дёшево и масштабируется на миллионы, но плеер ждёт, пока сегмент запишется и скачается. LL-HLS сокращает сегменты до частей по 0,2–0,5 секунды и в хорошей настройке даёт 2–5 секунд, но не меньше секунды.

WebRTC передаёт кадры по UDP сразу, без сегментов, и сам подстраивает битрейт под канал. Расплачиваться приходится трафиком: каждому зрителю нужен свой поток с медиасервера вместо копии файла из кэша. Поэтому зритель в WebRTC обходится дороже, а масштаб упирается в архитектуру, одной настройкой его не получить.

Почему «просто WebRTC» не выдерживает тысячи зрителей

Базовый WebRTC — соединение браузер с браузером (P2P). Видеочат так собрать несложно, но в сетке P2P на N участников нужно N × (N − 1) / 2 соединений, и источник отдаёт поток каждому зрителю сам. Уже на нескольких десятках зрителей канал и процессор ведущего заканчиваются.

Решение — медиасервер SFU (Selective Forwarding Unit). Он принимает один поток от источника и пересылает его каждому зрителю, не перекодируя. Чем SFU отличается от MCU и P2P, мы разобрали в статье об архитектурах WebRTC.

Каскад SFU: как WebRTC масштабируется на 10 000 зрителей

Один узел SFU обслуживает от 500 до 5000 подписчиков: всё зависит от битрейта, кодека и процессора. Дальше строят каскад. Главный SFU (master) принимает поток от источника и сам раздаёт его первым зрителям. Edge-узлы подписываются на главный и раздают поток своей группе. Чем больше зрителей, тем больше edge-узлов, и схема превращается в дерево.

Рисунок 2. Каскад SFU: главный медиасервер раздаёт поток edge-узлам, каждый обслуживает около 500 зрителей.

В Worldcast Live к одному главному узлу Kurento подключалось до 500 зрителей, каждый edge-узел добавлял ещё до 500. Каскад добавляет к задержке десятки миллисекунд на уровень, поэтому дерево держим неглубоким: обычно два уровня, edge-узлы — в регионах, где сидит аудитория.

Три вещи решают, выживет ли каскад под нагрузкой:

• Simulcast. Источник отправляет три слоя качества, например 180p, 360p и 720p, а SFU выбирает слой для каждого зрителя. Зритель на плохом канале переходит на 360p вместо того, чтобы замирать.
• SVC. Масштабируемое кодирование: один поток с несколькими слоями, меньше нагрузки на энкодер, чем у simulcast. Целевой вариант для новых проектов — AV1 SVC.
• TURN. По нашему опыту, 10–15 % зрителей сидят за симметричным NAT и получают поток только через TURN-ретранслятор. Недостаточный TURN — самая частая причина жалоб «у части зрителей зависает».

Как работают слои качества и как SFU переключает их, подробно объясняет урок нашего курса «Simulcast и SVC в SFU».

Kurento, LiveKit или mediasoup: на чём строить каскад в 2026 году

Worldcast Live мы строили на Kurento Media Server: на момент проекта это был самый зрелый WebRTC-сервер с открытым кодом. Kurento жив и сейчас (ветка 7.x, проект поддерживает команда OpenVidu), но для новых трансляций мы чаще берём LiveKit или mediasoup: у них встроенный simulcast, каскадирование между узлами и активное сообщество.

Подробнее о Kurento, его версиях и альтернативах — в статье Kurento Media Server в 2026 году.

Настройки кодирования, которые экономят сотни миллисекунд

Даже на правильном протоколе энкодер может съесть весь бюджет. Первое, что проверяем на аудите:

• B-кадры выключены. B-кадр ссылается на будущие кадры, поэтому энкодер их ждёт. Отключение экономит 50–200 мс при небольшой потере эффективности сжатия.
• Короткий интервал ключевых кадров. 1 секунда и меньше для интерактива: новый зритель быстрее получает первый кадр.
• Профиль для низкой задержки. Для x264 — tune=zerolatency и быстрый пресет: чуть больше битрейт, зато без внутренней буферизации.
• Аппаратное кодирование. NVENC, Quick Sync, VideoToolbox работают в разы быстрее программного энкодера; выше 1080p в реальном времени без них не обойтись.
• Кодек. H.264 даёт минимальную задержку кодирования и поддерживается везде. HEVC и AV1 экономят трафик, но добавляют время на кодирование; для них нужен запасной H.264.

Почему это работает и как устроены кодеки внутри, разбирает наш курс «Видеокодирование: от пикселя до энкодер-леддера».

Битрейт и качество картинки: почему настройки по умолчанию не подходят концерту

Браузер стартует WebRTC-поток с невысокого битрейта и наращивает его, пока оценка канала (алгоритм GCC) это позволяет. Для видеозвонка этого хватает. Концерту со сменой света и быстрыми движениями его мало: картинка рассыпается на квадраты, чтобы уложиться в канал.

В Worldcast Live мы подняли потолок битрейта видео до 1,5 Мбит/с через параметры кодирования (maxBitrate в RTCRtpEncodingParameters) и добавили динамическую подстройку качества: зрители на слабом канале получают более лёгкий слой, а не замирание.

Звук для концерта: стерео, многоканальность и частота дискретизации

WebRTC рассчитан на речь. Кодек Opus по умолчанию передаёт моно, а браузер включает обработку для разговора: шумоподавление, автоусиление, подавление эха. Для музыки всё это вредно: обработка срезает тихие партии и «съедает» реверберацию.

• Стерео. Включается параметром stereo=1 в описании Opus (RFC 7587) и повышенным битрейтом аудио.
• Многоканальный звук. В Worldcast Live звук идёт в 5 каналов: так зритель слышит сведение сцены, а не один микрофон. В Chrome многоканальный Opus работает через нестандартное расширение, поэтому эту часть тестируем на каждом обновлении браузера.
• Частота дискретизации. Opus работает на 48 кГц; важно, чтобы по пути звук не пересэмплировался в 16 кГц для речи и не терял высокие и низкие частоты.
• Обработка выключена. echoCancellation, noiseSuppression и autoGainControl отключаем для музыкального источника.

Джиттер-буфер, NACK и FEC: задержка против качества

Сеть доставляет пакеты неравномерно. Джиттер-буфер на стороне зрителя копит пакеты, чтобы выровнять поток: больше буфер — меньше заиканий, но выше задержка. С сентября 2026 года во всех основных браузерах есть свойство jitterBufferTarget у RTCRtpReceiver (MDN, Baseline 2026): приложение подсказывает, сколько миллисекунд держать в буфере, от 0 до 4000.

• Интерактив — буфер 50–100 мс: ведущий и зрители общаются, лучше редкая ступенька, чем отставание.
• Концерт без диалога — 200–500 мс: важнее непрерывный звук.
• NACK — переотправка потерянных пакетов по запросу; работает, пока сетевой RTT примерно до 150 мс.
• FEC — избыточные данные (10–20 % трафика), из которых зритель восстанавливает потери без переотправки.

Что такое джиттер и потери и как они съедают задержку, объясняет урок курса «Видеостриминг: от ингеста до экрана зрителя».

Кейс Worldcast Live: 0,4–0,5 секунды на 10 000 зрителей

Worldcast Live — платформа трансляций концертов в HD. Плеер встраивается на разные сайты, а концерт идёт на них одновременно. Требование было жёстким: зрители и исполнители общаются в прямом эфире, поэтому задержка выше секунды делала вопросы к сцене бессмысленными.

Первая стабильная версия с задержкой меньше секунды заняла у нас 3,5 недели разработки: это фактический срок проекта из первой версии статьи 2021 года, его мы не пересчитываем. Та же архитектура потом выдерживала концерты на несколько тысяч зрителей без серьёзной переделки.

Похожую задачу для трейдеров, где ведущий торгует в эфире, а больше 46 000 пользователей смотрят сделки и повторяют стратегии, мы решали в платформе прямых трансляций TradeCaster.

Сколько стоит доставка: цены за 1000 зритель-часов (ноябрь 2026)

Для сравнения берём 1000 зритель-часов видео 720p при битрейте около 2 Мбит/с, это примерно 0,9 ГБ на зритель-час. Считаем только доставку по публичным прайсам на 13 ноября 2026 года.

Источники: официальные прайс-листы Amazon IVS, Cloudflare Stream, LiveKit Cloud и Yandex Cloud Video, проверено 13 ноября 2026 года.

Главная статья расходов на масштабе — трафик. Поток 720p на 2 Мбит/с для 10 000 одновременных зрителей — это 20 Гбит/с, около 9 ТБ в час. В оригинале этой статьи 2021 года мы сравнивали почасовую аренду сервера WebRTC и HLS; сейчас честнее сравнивать цену зритель-часа: у управляемых сервисов WebRTC и LL-HLS стоят почти одинаково, а экономия появляется на собственном CDN с договорной ценой за гигабайт.

Россия: что доступно и где разворачивать

Для проекта в России список выше сокращается. Amazon с марта 2022 года не принимает новых клиентов из России и Беларуси, а соединения с Cloudflare с 9 июня 2025 года российские провайдеры ограничивают. Зарубежные облака остаются вариантом для аудитории за рубежом, но не для эфира на российских зрителей.

• Свой каскад SFU на LiveKit (self-hosted) или mediasoup в российском облаке или на своих серверах — основной путь для задержки меньше секунды.
• Российские CDN и Yandex Cloud Video — для массового слоя на HLS и LL-HLS.
• Персональные данные зрителей (аккаунты, чат, записи с лицами) по 152-ФЗ собираются и хранятся в России.

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

Гибрид: WebRTC для тех, кто говорит, LL-HLS для остальных

Многие живые продукты в 2026 году устроены как гибриды. Интерактивный слой (ведущие, гости, участники аукциона, обычно 10–200 человек) работает на WebRTC; массовый слой смотрит через LL-HLS и CDN. Между ними стоит композитор, который сводит картинку и звук в один поток.

Рисунок 3. Гибридная схема: интерактив по WebRTC для говорящих, LL-HLS через CDN для всех остальных.

Если в эфире говорят 200 человек из 10 000, каскад SFU и TURN нужны только для 2 % аудитории. Остальные видят эфир на 2–4 секунды позже, но им это не мешает: в разговоре они не участвуют. Когда нужно, чтобы задержка меньше секунды была у всех, например при ставках, гибрид не подходит, и считаем полный каскад.

WHIP, WHEP и MoQ: что меняется в 2026 году

• WHIP — стандарт RFC 9725 (март 2025): один HTTP-запрос поднимает WebRTC-сессию для отправки потока. OBS и облачные сервисы его поддерживают, поэтому энкодер подключается так же просто, как по RTMP, но без секунд задержки.
• WHEP — зеркальный протокол для просмотра. На 13 ноября 2026 года это черновик draft-ietf-wish-whep-05 (октябрь 2026) на рассмотрении в IESG, ещё не RFC, но в продакшене его уже используют.
• MoQ (Media over QUIC) — протокол IETF, который обещает задержку WebRTC при раздаче через релеи, как у CDN. Черновик транспорта дошёл до версии 23 (2 ноября 2026), стандарта пока нет.

Подробно о замене RTMP — в статье WHIP и WHEP вместо RTMP, о готовности MoQ — в разборе Media over QUIC в 2026 году.

Сколько времени займёт доработка трансляции до задержки меньше секунды

Если у вас уже есть WebRTC-трансляция и нужно довести её до задержки меньше секунды на 10 000 зрителей, работа состоит из шести блоков. Оценку считаем по типам работы: А — шаблонный код (инфраструктура, мониторинг), Б — продуктовая логика, В — тяжёлая инженерия (медиасерверы, кодеки, производительность), Г — то, что от скорости написания кода не зависит (нагрузочные тесты, приёмка). ИИ-инструменты ускоряют эти типы по-разному, поэтому один общий процент не годится.

Как считали: часы без ИИ × коэффициент по типу работы (А −70 %, Б −50 %, В −22 %, Г 0 %), калибровка Фора Софт от ноября 2026 года; календарь сокращён меньше часов (экономия × 0,75), неделя нагрузочных тестов не сокращается; серверы, трафик и лицензии в оценку не входят и от ИИ не дешевеют.

Публичные исследования влияния ИИ на скорость разработки расходятся, поэтому коэффициенты мы берём по своим проектам. Больше всего ИИ помогает в инфраструктуре и мониторинге и меньше всего — в тюнинге медиасервера, где решают замеры и опыт. Как устроена цена WebRTC-проекта целиком, разобрано в статье о стоимости разработки на WebRTC.

Как измерить задержку и что мониторить

Самый надёжный способ — снять камерой миллисекундный таймер, показать его в трансляции и сфотографировать рядом экран источника и экран зрителя: разница показаний и есть задержка. Замер повторяют 20 и больше раз и смотрят медиану и 95-й перцентиль. Для экспресс-проверки качества потока в браузере мы сделали расширение StreamTest для Chrome.

Внутри WebRTC метрики отдаёт getStats(). Средняя задержка джиттер-буфера считается так:

const stats = await pc.getStats();
stats.forEach(r => {
  if (r.type === 'inbound-rtp' && r.kind === 'video') {
    const jbMs = 1000 * r.jitterBufferDelay / r.jitterBufferEmittedCount;
    console.log('jitter buffer, ms:', jbMs.toFixed(0),
                'lost:', r.packetsLost, 'fps:', r.framesPerSecond);
  }
  if (r.type === 'candidate-pair' && r.nominated) {
    console.log('RTT, ms:', (r.currentRoundTripTime * 1000).toFixed(0));
  }
});

• Качество: задержка p50 и p95, потери пакетов (цель — меньше 2 %), доля замираний (меньше 1 % времени).
• Инфраструктура: загрузка CPU узлов SFU (до 70 %), загрузка TURN (до 60 % с автомасштабированием), время восстановления после падения edge-узла.
• Продукт: время до первого кадра, рассинхрон чата и видео (меньше секунды), доля зрителей на нижнем слое simulcast.

Пять ошибок, из-за которых задержка растёт

• Не тот протокол под задачу. Добиваться 500 мс на LL-HLS бесполезно, а раздавать 100 000 зрителям чистый WebRTC — дорого. Сначала сценарий, потом протокол.
• Мало TURN. Зрители за симметричным NAT зависают первыми, а в логах сервера всё выглядит нормально.
• Нет simulcast. Если зритель на мобильном интернете получает один поток 720p, он отстаёт или замирает.
• Оставлены B-кадры. На каждом аудите интерактивных потоков с B-кадрами мы находили 100–200 мс лишней задержки.
• Глубокий каскад. Каждый уровень дерева добавляет задержку; три-четыре уровня вместо двух быстро съедают запас.

Как выбрать: пять вопросов перед стартом

Рисунок 4. Пять вопросов, которые сужают выбор архитектуры трансляции до одного-двух вариантов.

1. Какая задержка допустима? До 0,5 с — WebRTC или MoQ; 2–5 с — LL-HLS; больше — обычный HLS.
2. Сколько зрителей в пике? До 1000 — один SFU; до 10 000 — каскад или гибрид; больше — гибрид с CDN.
3. Сколько людей говорит в эфир? До 200 — WebRTC для них, остальным LL-HLS.
4. Какая цена зритель-часа приемлема? Если меньше 3 центов, нужен свой LL-HLS через CDN с договорной ценой; управляемые сервисы стоят 5–7 центов.
5. Задержка — условие продукта или приятный бонус? Для ставок и торгов вкладываемся в каскад сразу; для концертов можно стартовать с LL-HLS.

Когда задержка больше секунды — нормально

Задержка меньше секунды стоит денег и сил. Она не нужна, когда:

• зритель только слушает и смотрит — лекция без вопросов, концерт без чата, новостной эфир;
• запись важнее эфира — большая часть просмотров приходится на запись, а не на прямой эфир;
• продукт на стадии MVP — сначала проверяем спрос на LL-HLS, а к WebRTC переходим, когда интерактив подтвердил ценность.

В исходной версии статьи мы задавали тот же вопрос: если вы не проводите интервью во время концерта, стоит ли вкладываться в задержку меньше секунды? Ответ прежний: сначала посчитайте свой сценарий.

Итог: что нужно, чтобы трансляция шла быстрее секунды

Задержка меньше секунды для тысяч зрителей складывается из WebRTC на всём пути, каскада SFU, настроек кодирования и буфера и постоянного замера. В Worldcast Live эта связка дала 0,4–0,5 секунды на 10 000 зрителей. С тех пор появились WHIP для ингеста (RFC 9725, 2025), jitterBufferTarget во всех основных браузерах (2026) и гибрид с LL-HLS, который снижает цену массового слоя. Если сценарий требует интерактива, начинайте с бюджета задержки по этапам и честного расчёта цены зритель-часа.

Частые вопросы о задержке WebRTC-трансляций

Какая задержка у WebRTC?

В одном регионе на нормальной сети — 150–400 мс от камеры до экрана. Тест Wowza (октябрь 2026) показал 258 мс при RTT 130 мс и 367 мс с восстановлением потерь.

Можно ли сделать трансляцию с задержкой меньше секунды на тысячи зрителей?

Да. Нужен WebRTC и каскад медиасерверов SFU. В нашем проекте Worldcast Live задержка 0,4–0,5 секунды при 10 000 одновременных зрителей.

Почему HLS не даёт задержку меньше секунды?

Плеер HLS ждёт, пока сегменты запишутся и скачаются, и держит буфер. Даже LL-HLS в хорошей настройке даёт 2–5 секунд.

Сколько зрителей выдерживает один WebRTC-сервер?

Один узел SFU — от 500 до 5000 подписчиков в зависимости от битрейта, кодека и процессора. Дальше подключают edge-узлы каскадом.

Как уменьшить задержку WebRTC?

Отключите B-кадры, сократите интервал ключевых кадров, включите simulcast, подберите jitterBufferTarget под сценарий и держите каскад SFU не глубже двух уровней.

Что дешевле: WebRTC или LL-HLS?

У управляемых сервисов в ноябре 2026 года цена почти одинаковая: $48–72 за 1000 зритель-часов 720p. Экономию даёт свой LL-HLS через CDN с договорной ценой трафика или гибрид, где WebRTC получают только говорящие.

Можно ли использовать Kurento в 2026 году?

Да, Kurento развивается в ветке 7.x. Для новых массовых трансляций мы чаще выбираем LiveKit или mediasoup из-за встроенного simulcast и каскадирования.

Сколько времени займёт доработка трансляции до задержки меньше секунды?

Для 10 000 зрителей — 5–7 недель с ИИ-инструментами (6–9 недель у команды без них), 280–420 часов против 420–640. Серверы и трафик оплачиваются отдельно.

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