WHIP: трансляции из OBS с задержкой менее 1 секунды.

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

Такая короткая задержка сделала этот протокол очень привлекательным для сферы прямых трансляций, где в стандартной цепочке доставки потока каждый этап обработки добавляет задержку, и контент доходит до зрителя лишь через 10–30 секунд после подачи сигнала. А при нестабильной сети плеер увеличивает буфер дополнительно и задержка может вырасти до 40–60 секунд.

Однако применить WebRTC в стриминге оказалось непросто.

Дело в том, что перед стартом потока, энкодер и платформа должны «договориться» — обменяться описанием кодеков, маршрутов, параметров шифрования. В RTMP этот обмен описан в спецификации с самого начала, поэтому любой энкодер работает с любым сервером без дополнительных настроек.

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

В марте 2025 года вышел RFC 9725 (RFC — официальный технический стандарт интернета) — документ, который наконец описал единый стандарт подключения энкодеров к WebRTC-серверу. Назвали его WHIP (WebRTC-HTTP Ingestion Protocol).

После этого осталось лишь дождаться, когда популярные энкодеры добавят нативную поддержку протокола. И в октябре 2023 в OBS 30.0 добавили поддержку WHIP «из коробки», без плагинов и патчей.

Далее расскажем о том, как устроен этот протокол, где его уже можно применять, где нельзя, а где не нужно.

Что такое WHIP

WHIP (WebRTC-HTTP Ingestion Protocol) — протокол передачи медиапотока от энкодера на WebRTC-сервер. Проще говоря, это мост между энкодером и медиасервером: принял поток на входе, передал дальше — и на этом его задача заканчивается.

Подключение строится на HTTP-обмене: энкодер сообщает серверу, что готов передавать поток,  а также какие кодеки и параметры потока использует. Сервер отвечает, на каких условиях готов принять. После этого стороны согласовывают маршрут соединения, обмениваются ключами шифрования — и поток стартует. Весь медиатрафик передаётся зашифрованным по умолчанию, в отличие от RTMP, где шифрование настраивается отдельно.

Дальнейший маршрут зависит от задачи. Поток можно направить на SFU — это сервер, который раздаёт его зрителям напрямую по WebRTC с задержкой менее секунды: идеально для интерактивных эфиров, где важна мгновенная реакция аудитории. Или через транскодер упаковать в HLS и раздать через CDN — задержка выше, зато поток масштабируется до практически любого количества зрителей и лучше переживает кратковременные проблемы с сетью за счёт буфера на стороне плеера. Оба сценария совместимы: один поток на входе, два контура раздачи на выходе.

Его парный протокол — WHEP (WebRTC-HTTP Egress Protocol) — закрывает обратную сторону: доставку потока от медиасервера до плеера зрителя. WHIP принимает поток от стримера, WHEP отдаёт его аудитории — вместе они покрывают весь путь потока от начала до конца.

Главный выигрыш от использования — эксплуатационный, а не технический. Протокол не делает WebRTC значительно быстрее, чем хорошо написанная кастомная интеграция. Он убирает необходимость эту интеграцию писать каждый раз заново.

Что даёт WHIP на практике

• WHIP стандартизирует подключение. Любой совместимый энкодер работает с любым совместимым сервером по единому принципу — без изучения кастомного API каждой платформы.
• Шифрование всегда включено. В отличие от RTMP, где защищённая передача настраивается отдельно, WHIP шифрует поток по умолчанию — это часть стандарта, а не опция.
• Нативная поддержка современных кодеков. Энкодер передаёт H.265 или AV1, сервер их принимает — промежуточное перекодирование на входе не требуется. Это сокращает задержку и снижает нагрузку на сервер.
• Симулкаст — несколько качеств в одном потоке. WebRTC позволяет одновременно передавать несколько версий потока с разным разрешением. Сервер выбирает нужное качество для каждого зрителя в зависимости от канала — без транскодирования на лету. При RTMP поток транскодируется уже на сервере после приёма: это дополнительная обработка, которая увеличивает задержку. OBS 32.1 добавил поддержку симулкаста в связке с WHIP (март 2026).
• Снижение задержки за счёт упрощения цепочки. В схеме RTMP → WebRTC задержка между камерой и экраном зрителя была около полсекунды: часть времени уходила на приём потока по RTMP, буферизацию и перекладку его в WebRTC-формат на сервере. При переходе на WHIP и прямой WebRTC-приём с OBS эта обработка на входе больше не нужна, и общая задержка в тестах уменьшалась примерно до 200 мс.

Где WHIP уже интегрирован

WHIP в Facecast

За последний год, к нам пришло много запросов на добавление протокола, и в прошлом месяце Facecast получил поддержку WHIP. Мы уже успели провести ряд успешных трансляций с задержкой около 1 секунды, а также добавили возможность симулкаста — когда OBS одновременно отправляет несколько версий потока в разном качестве, а сервер сам выдаёт каждому зрителю подходящую без транскодирования на лету.

Раздача через WebRTC-плеер поддерживает участие 10 000 одновременных зрителей и более. Зависит от ваших задач.

Пока функционал доступен по запросу — напишите нам.

Как подать поток по WHIP из OBS:

1. Откройте OBS → Настройки → Трансляция
2. В поле Служба выберите WHIP
3. Вставьте полученную от нас WHIP-ссылку в поле Сервер
4. В поле «Токен предъявителя» можно вставить токен авторизации — это ключ доступа, который подтверждает, что именно вы имеете право вещать на этот эндпоинт; в случае с Facecast этот токен не требуется, оставьте поле пустым
5. Перейдите в Настройки → Вывод и убедитесь, что видеокодек — H.264; аудио (Opus) согласуется автоматически
6. Запустите трансляцию

WHIP: когда использовать и когда не нужен

Вывод