2026.10.14
MiroTalk BRO: A WebRTC Platform for Self-Hosted Live Rooms
MiroTalk BRO is for teams that want to operate their own live-broadcast entry point, with video, audio, screen sharing, and RTMP ingest. Review SFU, network, browser, and AGPLv3 considerations before adopting it.
What it is for
MiroTalk BRO is an open-source, self-hosted WebRTC live-broadcasting platform for sending real-time video, audio, and screen content to connected viewers. The project presents webinars, online events, presentations, announcements, and other live communication as target use cases. Unlike a hosted video service, the operator is responsible for the runtime environment, access endpoint, networking, and ongoing administration.
Who it may suit
The project is a reasonable candidate for developers, small teams, educators, or event organizers who want control over where and how their broadcasting service is operated. Its room model has one broadcaster and many viewers, and the README describes rooms as having no time limits. That does not establish a supported concurrency limit: the supplied project materials do not specify standard hardware, a viewer ceiling, or a performance guarantee.
Documented capabilities
Broadcasts can use a camera, microphone, and screen sharing. The project offers P2P and SFU broadcasting modes; the README says that SFU deployments must meet mediasoup installation requirements. It also documents Docker Compose and local Node.js deployment paths, alongside configuration, automation, integration, direct room joining, and REST API documentation.
Camera background options are Off, Blur, and Image. Image backgrounds can be local PNG, JPEG, or WebP files up to 10 MB, and are not uploaded to the server. Processing occurs in the broadcaster’s browser, so browser capabilities and device load matter. When effects are enabled, output is capped at 1280×720 and 15 FPS; with effects off, the camera can retain its resolution and reach up to 60 FPS. Actual results depend on the device. Screen sharing and RTMP sources do not use these browser camera effects.
RTMP ingest allows hardware or software encoders such as Blackmagic ATEM, OSEE, or OBS to act as the broadcaster. This route requires SFU mode, FFmpeg, and MediaMTX. It also involves a publish token, a reachable announced address, and configuration of the mediasoup UDP/TCP port range.
Limits and deployment considerations
Deployment responsibility remains with the operator: dependency installation, environment variables, reverse proxying, networking, exposed ports, and access control all need to be planned. For remote deployments, or Docker deployments behind NAT, the README says the mediasoup announced address must be a public IP or hostname reachable by viewers. A loopback address is not suitable for remote viewers.
Browser background effects are conditional rather than universal. They require WebGL2 and canvas stream capture; blur also requires canvas filter support. The pinned MediaPipe runtime and model assets are loaded from jsDelivr and Google Storage, so a custom CSP or network policy must permit those hosts. If initialization fails, the application falls back to the camera without effects. The supplied materials do not confirm compatibility across all browsers, mobile devices, or network conditions, so a production event should include its own validation.
MiroTalk BRO is licensed under AGPLv3. Teams offering modified software as a network service should review the complete license and the project’s licensing guidance with technical and legal stakeholders. The README also mentions commercial licensing with different terms, but the supplied sources do not confirm its price, rights, or eligibility.
Sources
Sources checked: 2026-10-14