One Restreaming Hub, Many Cameras, One Silent Rejection

Centralizing several different cameras' RTSP feeds behind one restreaming layer solved the fan-out problem cleanly — until one camera with no audio track at all ran into a YouTube health check nobody expects to fail on video grounds.

July 30, 2026

This article is also available in Traditional Chinese: 中文版 — same content, just a language difference.

Once you have more than one camera you want live on YouTube, "run a separate ffmpeg process per camera" stops scaling cleanly — different camera brands speak different proprietary variants of RTSP, and duplicating encoding logic per source is exactly the kind of thing worth centralizing once instead of copy-pasting per device. Centralizing it exposed a genuinely surprising YouTube requirement: a live stream can fail its health check for having no audio — even when the video feed is perfect.

The fan-out problem, and why one restreaming hub beats N ffmpeg processes

Different camera hardware speaks meaningfully different flavors of "RTSP" — some genuinely standard, some using a manufacturer-proprietary variant that a generic RTSP client can't talk to directly at all, needing brand-specific protocol support instead. Running a fully separate capture-and-encode pipeline per camera, per brand, means duplicating connection logic, credential handling, and reconnect/health behavior N times, with N chances to drift out of sync with each other. Centralizing all of it behind one restreaming service — something that speaks each camera's native protocol on the input side and re-exposes a single normalized RTSP/WebRTC output per camera on the output side — turns "add a new camera" into "add one config entry," rather than "build a new pipeline."

Unlock this article to keep reading, or subscribe for unlimited access to everything. See Pricing for details.