⚠ Notice! We've rebranded from OBS.Ninja to VDO.Ninja - all else is staying the same ✨ What is VDO.Ninja? 🚀 VDO.Ninja brings peer-to-peer video to OBS and other studio software, for remote cameras and guests: 🔒 Direct peer-to-peer video transfer in most cases ⚡ High-quality video with low latency 💪 Director control room with group chat 📱 Use a smartphone as a wireless webcam 🌐 Supports WHIP/WHEP and self-hosted…
Publish from OBS, receive streams, and add room participants as OBS sources. OBS 32 on Windows, macOS and Linux; the native receiver and transparent Game Capture workflow are experimental.
OBS fork with WHIP trickle ICE and better TURN connectivity. Builds of OBS 32.2.2 and OBS 33 beta for Windows, macOS and Linux; check each release’s limitations.
Publish or receive without a browser, using Python and GStreamer on Raspberry Pi, Linux, Jetson, macOS or WSL. Hardware encoding, WHIP output and computer-vision workflows.
Server-assisted distribution for larger rooms and one-to-many streams, so the publisher uploads less. The newer app supports WHIP, RTMP and SRT; RTMP and SRT need an account.
Flip, mirror or rotate websites, chat overlays and VDO.Ninja feeds for teleprompter displays.
What’s in this repo
The VDO.Ninja web frontend and sample apps that use its IFRAME API. Production backends and operational scripts live in separate repositories. User documentation is at docs.vdo.ninja.
Hosting and local development
To host the frontend, serve this repository from an HTTPS-enabled static web server. There is no build step.
What you want to host
Guide
What it provides
The website on your own web server or GitHub Pages
The website, a local secure handshake server and certificate instructions. Docker is optional.
For a local preview, run this from the repository root and open http://localhost:8080/:
python -m http.server 8080 --bind 127.0.0.1
This server does not map addresses without .html, so open other pages with the extension (for example /mixer.html). Other devices need HTTPS. The preview serves only the frontend; rooms still use the configured signaling and relay services.
Before you open a pull request, run the translation checks (they need Node.js), then test the flows you changed in a browser:
Release branches: each release has its own branch, which gets only bug and critical fixes.
https://vdo.ninja/: updated infrequently, because surprise changes are unwelcome in live production and make support harder. For newer features, use https://vdo.ninja/alpha/.
Backend services and self-hosting
The browser uses a signaling server to set up rooms and peer connections. STUN helps peers find their network addresses, and TURN relays traffic when a direct connection fails. Hosting the frontend does not deploy these, or the authentication and call-in backends.
Signaling:websocket_server provides standalone handshake servers. Use &wss2= for its advanced routing server (vdoninja_advanced.js) and &wss= for the older fanout servers, on both publisher and viewer links.
TURN:turnserver.md and the turnserver_basic.conf and .sample files are self-hosting examples that the website does not run. Replace their placeholders before use.
Call-in: SIP call-in uses the provider settings you enter. Twilio call-in needs a Worker backend whose code is not in this repository; it defaults to a hosted Worker (vdo-callin-alpha.vdo.workers.dev), and &callinapi= (alias &twilioapi=) sets your own.
Live translation: uses your own API key or a separately deployed token broker, such as the included token broker example.
Offline:offline_deployment pairs the website with a local advanced routing server and turns off automatic public STUN/TURN. Its guide covers setup, connection checks and optional internet-assisted connections.
Phones and other remote clients need HTTPS even on a private LAN. With a private certificate authority, trust its root certificate on each client device; see the certificate guide for browsers, OBS and native apps.
Self-hosting the frontend does not by itself make a deployment independent of hosted services, so review the endpoints your features use. LICENCE.md explains the difference between the software license and access to hosted services.
How VDO.Ninja works
VDO.Ninja sends audio and video directly between devices using WebRTC. The website only delivers the app, and the signaling (handshake) server only helps devices find each other and exchange connection details; neither carries the live stream. Devices on the same local network usually keep the stream on that network, but loading the page and the handshake still need internet unless you run the offline deployment.
When a direct route is not possible, a TURN server relays the encrypted packets without decoding them. With optional Meshcast, or another SFU (a media server that receives one upload and forwards it to many viewers), the publisher sends one stream and the server distributes it.
VDO.Ninja avoids data collection where possible, and streams are designed to be private, but use it at your own risk and share links only with people you trust. To keep your IP address private, use your own TURN server with forced relaying; see turnserver.md.
https://vdo.ninja may use cookies that the service needs to work, which are exempt from EU cookie-notice rules. Cloudflare caches the site and provides denial-of-service protection. If you need extra security or privacy features, ask; many have been added on request.
Thank you to everyone who has supported this project: the moderators, support volunteers, media contributors, sponsors, and everyone who has reported issues, offered feedback or submitted code.
评论