SubSecondStreaming
A private, sub-second-latency streaming network, built from scratch and run like a CDN.
No Third-Party Relay in the Middle
VRChat's built-in video players can stream from anywhere on the internet, but "anywhere" usually means multiple seconds of delay, a shared public relay you don't control, and no say in quality, privacy, or reliability.
SubSecondStreaming is my answer to that: a private, purpose-built streaming network that gets an OBS broadcast into a VRChat world in under a second, worldwide. There's no third-party relay in the middle, and a viewer's stream key is never exposed to anyone watching. If someone on the other side of the planet has a worse time than everyone else, I can actually find out why, because I built, monitor, and tune this network myself.
Streaming & Playback
- Push a stream from OBS and get back a link that just works in ProTV, USharpVideo, or VideoTXL. No plugin, no special client, no per-viewer setup.
- Sub-second glass-to-glass latency on PC and Quest: low-latency RTSP for desktop AVPro playback, low-latency HLS with 200ms parts for standalone headsets and browsers.
- Paired HQ/LQ delivery. One stream goes in, two quality tiers come out, so viewers on a good connection get the crisp version and everyone else still gets something smooth.
Security & Control
- Every playback link is a disguise. Viewers get a friendly public slug (
/yourshow), never the broadcast key. Share the link anywhere: the key that lets someone broadcast as you stays private, always. - Streamers manage themselves. A private self-service page shows live status, bitrate, viewer count, and connection history, and lets a streamer rotate their own key instantly. No admin required, no downtime.
- An admin console, not a spreadsheet. Live service health, per-stream bitrate and reader counts, a color-coded security event feed, and live-tailed logs for every moving part, all in one dashboard.
At A Glance
Sub-Second Latency
RTSP (PC) + Low-Latency HLS (Quest/browser).
Global Edge Routing
GeoDNS automatically sends viewers to the nearest node.
HQ/LQ Tiers
One broadcast, two quality options for viewers.
Key-Safe Links
Public slugs. The stream key is never exposed.
Self-Service Rotation
Streamers manage their own security, instantly, no downtime.
Live Admin Dashboard
Health, bitrate, viewers, security events, and logs on one screen.
Real-Time Diagnostics
Custom monitoring built to catch problems during live broadcasts.
Proper Accounts
Sessions, roles, CSRF protection, rate-limited login.
Why It Exists
Off-the-shelf relay services are convenient, but you have no visibility into them. When something's slow, you can't see why and you can't fix it. SubSecondStreaming puts that control back in one place: one person running the infrastructure, able to look at a problem and answer why instead of shrugging at a status page.
How It's Built
This isn't a wrapper around someone else's service. I designed, built, and actively operate every layer end to end: the ingest and relay pipeline, the authentication and account system, the admin tooling, and the network topology it runs on.
Signal Path
OBS Broadcast
Encoder push
Private Ingest / Relay
Origin server
GeoDNS Edge Routing
Multi-continent nodes
VRChat Player
RTSP / LL-HLS, same URL
The Cross-Continent Bottleneck
I once had to diagnose and fix a cross-continent performance bug. Viewers on one side of the Atlantic were getting unwatchable video while everyone else had a great experience, and the obvious suspects (server load, CPU, bad code) were all clean. I root-caused it by reading raw proxy and relay logs down to the packet level, cross-referencing client-side encoder logs against server timestamps across time zones, and running live traceroutes. The actual problem was bandwidth saturation on the single origin server, which punished the highest-latency viewers first.
Building the Edge Network
To fix it properly, I designed and deployed a geographically distributed edge network. Instead of patching around the symptom, I built a second relay node on another continent and wired it in with GeoDNS-based automatic routing, so every viewer's player, using the exact same unchanged URL, gets quietly steered to whichever server is actually closest to them. I built and wired that edge network by hand, not bought off a shelf.
Operational Tooling
I built the operational tooling to run it, too. A live control panel lets me stand up, monitor, and, if needed, instantly roll back the edge network, with health checks visible at a glance. Custom lightweight monitoring probes ride along during live broadcasts, sampling bitrate, viewer counts, and packet-level health every few seconds. So the next time something goes wrong, I have hard data waiting instead of a guessing game.
Secure By Default
Every account runs through a session-based auth system with role separation between admin and streamer, CSRF-protected mutations, and rate-limited login attempts. Stream keys are never sent anywhere they don't strictly need to be, and they never appear in a shareable link.
Keeping The Lights On
I've also handled a production incident live: a storage crisis on the origin server. I found and cleared the actual sources of unbounded growth instead of just buying more disk, and kept the stream up the whole time.
Building Something Similar?
SubSecondStreaming is private and purpose-built for its own network, but the engineering behind it (edge routing, secure ingest, live observability) is the kind of thing I build for a living.
Establish Secure Comms