Show HN: OBS Live-streaming with 120ms latency

Original Article ↗ Hacker News Discussion ↗

Latency vs existing streaming

  • OP reports ~120 ms glass-to-glass using OBS + Broadcast Box over a ~37 ms RTT link on modest hardware (Thinkpad T420, Linux).
  • Commenters note most consumer live streams (HLS/DASH, cable, many “live” TV feeds) are seconds to tens of seconds behind; sub-second has existed in pro setups but is rarely used.
  • Some argue that for most content, viewers care more about quality than delay; others say sports and live betting strongly benefit from ultra-low latency.

Why low-latency is hard

  • Traditional HTTP streaming (HLS/DASH) uses segmented MP4/TS, manifests, and large client buffers, all adding latency (segment packaging, manifest RTT, playback buffer).
  • Efficient encoders use B-frames and lookahead, adding tens of ms.
  • For mass distribution, streams must be CDN-cacheable, which fits poorly with ultra-low-latency designs.
  • Many intermediaries buffer conservatively to cope with jitter and poor connections.

WebRTC, WHIP/WHEP, and scaling

  • Broadcast Box uses WebRTC with WHIP (ingest) and WHEP (playback) for sub-second latency.
  • WebRTC itself can do <<1s, but large-scale fanout (100k+ viewers) is non-trivial; requires SFUs and custom infrastructure.
  • Cloud vendors (e.g., Cloudflare Stream WebRTC beta) and commercial services (Twitch IVS, Dolby Millicast, Phenix, etc.) target this space; open source “instant scalability” is seen as lacking.
  • Some propose chaining Broadcast Box instances into a tree for higher fanout.

Encoding, transcoding, and codecs

  • Broadcast Box relies on client-side simulcast: OBS sends multiple renditions; the server just forwards the selected layer.
  • Advocates say this avoids server transcoding latency/quality loss, reduces infra cost, and keeps servers from modifying content, enabling future end-to-end encryption.
  • Others note this increases CPU/GPU load on broadcasters, especially game streamers.
  • WebRTC is codec-agnostic; H.264/VP8 are common, H.265/AV1 are emerging (some require browser flags).

Cloud gaming vs livestreaming

  • Cloud gaming usually involves one server–one client with minimal buffering and often GPU-assisted zero-copy pipelines.
  • Broadcast-style streaming adds server-side fanout, CDNs, ABR logic, and more buffering, making similar latencies harder.

Real-world use cases and experiences

  • Suggested uses: co-streaming, “backstage” feeds, remote RPG sessions, collaborative work, and small intimate audiences.
  • Some report good low-latency remote-desktop/gaming via Moonlight/Sunshine; others insist even 40 ms added latency is very noticeable for competitive play.
  • A user seeking a self-hosted family video chat alternative hears suggestions like using Broadcast Box, Galène, Jitsi (self-hosted in a nearer region), or Cloudflare as WHIP target.

NAT, TURN, and connectivity

  • One commenter argues WebRTC is often unusable behind symmetric/CGNAT without TURN; others counter that many one-way or SFU-based setups work fine without public TURN, and large services may rely on their own relays or TCP fallbacks.
  • Running an SFU or Broadcast Box on a public VPS is presented as a practical way to avoid TURN for group viewing.

Latency measurement skepticism

  • Linked article on “how to lie about latency” triggers debate: photos of clocks are criticized as cherry-picking best-case frames; some emphasize P99 latency over minimums.
  • Others describe long-term streams where poorly configured ffmpeg pipelines accumulate “latency creep,” versus professional encoders that reportedly do not.