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