\n<\/p>\n
By Dacast Editorial Team | Reviewed by Jon Whitehead, COO at Dacast | Updated April 2026<\/span><\/i><\/p>\n Going live from a browser should be the easy part. No encoder to install, no settings to dig through, just open Dacast, hit Go Live, and you\u2019re streaming. That simplicity hasn\u2019t changed. But the infrastructure making it possible just got a serious upgrade.<\/span><\/p>\n Dacast has migrated its <\/span>WebRTC ingest<\/span><\/a> to WHIP, a modern standard that puts browser-based streaming on the same technical footing as RTMP and SRT. In plain terms: the engine under the hood is now faster, more reliable, and built to last. If you\u2019ve ever had a Go Live session behave unexpectedly, or if you\u2019re a developer looking to build on top of Dacast\u2019s ingest, this one\u2019s for you.<\/span><\/p>\n Dacast upgraded the engine behind its Go Live feature. Browser-based streaming now runs on the same modern pipeline as RTMP and SRT; more reliable, more consistent, and open to developers via a standard called WHIP. The experience looks identical. What\u2019s underneath is meaningfully better. <\/span>One thing it doesn\u2019t do yet: sub-500ms ultra-low latency delivery. That\u2019s a separate project, and this upgrade is a step toward it.<\/span><\/p>\n Dacast has migrated its browser-based \u201cGo Live\u201d feature to WHIP,\u00a0 the WebRTC-HTTP Ingestion Protocol, as part of a broader investment in a unified, modern ingest pipeline. This update affects every Dacast user who streams directly from a browser, and opens new doors for developers building custom WebRTC ingest workflows.<\/span><\/p>\n Here is a summary of what changed:<\/span><\/p>\n WHIP (WebRTC-HTTP Ingestion Protocol) is a standardized protocol developed by the <\/span>IETF<\/span><\/a>, designed specifically for WebRTC-based ingest. It defines how a WebRTC stream is pushed from a client (a browser, an encoder, or a custom app) to a media server over HTTP. Think of it as doing for WebRTC what RTMP did for encoder-to-server communication: creating a reliable, predictable, and widely interoperable standard.<\/span><\/p>\n Before this upgrade, every platform implementing WebRTC ingest, including Dacast, had to build proprietary signaling and handshake logic from scratch. That led to fragmented systems that were hard to integrate with external tools. WHIP standardizes that handshake.<\/span><\/p>\n By adopting WHIP, Dacast aligns with where the broader industry is heading and makes WebRTC ingest more predictable, interoperable, and easier to build on.<\/span><\/p>\n Previously, the Go Live feature relied on a legacy AMS-based infrastructure. It worked, but it was isolated : WebRTC channels weren\u2019t integrated with the new ingest pipeline (ingest v2 \/ SRS-based) that powers RTMP and SRT on Dacast. That meant WebRTC users weren\u2019t benefiting from pipeline-level improvements, and the architecture was inconsistent.<\/span><\/p>\n That\u2019s now changed. WebRTC ingest runs on the same modern infrastructure as RTMP<\/a> and SRT. Stream key rotation works consistently across all three protocols. This reduces edge cases, simplifies stream management, and makes the overall system more robust and easier to maintain.<\/span><\/p>\n The WHIP endpoint is now visible in the encoder setup section of your Dacast account and available through the API. This makes it possible for developers to build custom WebRTC ingest workflows, not just use the built-in Go Live tool.<\/span><\/p>\n This is an important capability unlock: any tool or encoder that supports WHIP can now connect directly to Dacast\u2019s ingest infrastructure without custom integration work.<\/span><\/p>\n As part of this project, Dacast\u2019s engineering team developed WHEP (WebRTC-HTTP Egress Protocol) support and contributed it upstream to <\/span>FFmpeg<\/span><\/a>, the widely-used open-source media framework (PR #21603). WHEP is the playback counterpart to WHIP: it standardizes how clients connect to and decode WebRTC streams. This contribution extends the broader ecosystem\u2019s compatibility with WebRTC ingest workflows and reflects Dacast\u2019s investment in open-source streaming infrastructure.<\/span><\/p>\n This update is primarily about reliability and architectural integrity. Here\u2019s what it means in practice:<\/span><\/p>\n One important note: this update does not introduce ultra-low latency (sub-500ms) delivery. WebRTC ingest is now more reliable and standardized, but Dacast\u2019s current delivery layer still uses <\/span>HLS<\/span><\/a>. Ultra-low latency playback is a separate capability, one that this infrastructure makes easier to build toward.<\/span><\/p>\n The Go Live feature is designed for browser-based streaming, no encoder required. But if you prefer to use <\/span>OBS<\/span><\/a> or another WHIP-compatible encoder, you now have a direct path to do that on Dacast.<\/span><\/p>\n This is the simplest option and requires no additional software:<\/span><\/p>\nTL;DR<\/strong><\/h4>\n
Table of Contents\u00a0<\/b><\/h2>\n
\n
What\u2019s New<\/strong><\/h2>\n
\n
What Changed<\/strong><\/h2>\n
WebRTC Ingest Now Uses WHIP<\/strong><\/h3>\n
A Unified Ingest Pipeline<\/strong><\/h3>\n
WHIP Endpoint Now Accessible in the UI and API<\/strong><\/h3>\n
WHEP Contributed to FFmpeg<\/strong><\/h3>\n
Why This Matters<\/strong><\/h2>\n
\n
How to Use the Go Live Feature \u2013 Including with OBS<\/strong><\/h2>\n
Option 1: Go Live Directly from Your Browser<\/strong><\/h3>\n