Термин
WebRTC ingest
Использование WebRTC в качестве протокола для передачи контента – субсекундная альтернатива RTMP и SRT для источников из браузеров и потоковых рабочих процессов с низкой задержкой. Обычно сигнализация осуществляется через WHIP.
WebRTC-ингест использует тот же WebRTC-стек, что и Google Meet с Zoom, и направляет его на сервер live-ингеста. Браузер (или нативное WebRTC-приложение, или OBS с WHIP-плагином) устанавливает PeerConnection с сервером ингеста, согласует SDP и начинает отправлять RTP-пакеты с видео в форматах H.264, VP8, VP9 или AV1 и аудио в формате Opus. Сервер ингеста демультиплексирует поток, при необходимости декодирует его для транскодирования и передаёт дальше по пайплайну.
Преимущество – низкая задержка. Где RTMP добавляет 2–5 секунд, WebRTC-ингест – всего 100–500 мс. Для интерактивного стриминга – аукционов, ставок, видеосвязи, онлайн-уроков – эта разница имеет значение. Второе преимущество – нативная поддержка в браузере: WebRTC работает в любом современном браузере без плагинов, поэтому любое веб-приложение может стать источником трансляции без установки дополнительного ПО. Это позволяет создавать приложения типа «экран в стрим», браузерные инструменты для киберспорта и удалённые рабочие процессы в производстве контента.
Минус – операционная сложность. WebRTC требует STUN- и TURN-серверов, ICE-согласования, RTP с управлением перегрузкой, обработки NACK и PLI – гораздо более тяжёлый стек, чем TCP-сокет RTMP. Облачные сервисы (Cloudflare Stream, Mux, Dolby.io, AWS) скрывают эту сложность за WHIP-URL. Самостоятельный хостинг возможен на mediasoup, Pion или Janus, но требует значительно больше инфраструктуры, чем nginx-rtmp endpoint.
Считаете параметры для своего продукта?
Поможем собрать энкодер-леддер и посчитать стоимость доставки – до старта разработки.