Engineering case study
This is a breakdown of the video infrastructure behind OurBlock, a 24/7 multi-camera security platform I run as solo founder. The constraint that shaped every decision: it has to run on commodity mini-PC hardware sitting in a guard cabin, not a beefy cloud GPU box.
Video transcoding
None
RAM in production
< 1 GB
Hardware
Intel N100
Multiple Hikvision cameras stream simultaneously over RTSP. The obvious approach — decode and re-encode each stream for web playback — is exactly what an Intel N100 can't afford to do for more than one or two cameras at once. Transcoding is CPU-expensive by nature, and a security platform can't degrade or drop cameras as more get added.
The fix was to not transcode at all. The pipeline remuxes each RTSP stream to HLS with FFmpeg — repackaging the existing H.264 bitstream into a browser-playable format without touching the actual video encoding. No decode, no re-encode, just a container format change. That's the difference between the pipeline needing GPU-class hardware and running comfortably on a fanless mini PC.
Each camera runs as its own managed child process rather than one process handling all streams. This has a direct operational benefit: if one camera's RTSP connection drops or a stream corrupts, it doesn't take down the others. Each process is monitored with health checks and gets auto-restarted independently on failure — a flaky camera degrades gracefully instead of cascading into a full outage.
The React dashboard needs to reflect camera health and stream status in real time — whether a feed is live, reconnecting, or down. Rather than polling an endpoint on an interval, status updates push to the frontend via Server-Sent Events, so the UI reflects state changes as they happen instead of on the next poll cycle.
Alongside the live HLS path, each camera dual-records locally to MKV with 30-day retention on the mini PC itself, plus a throttled sync to Backblaze B2 for offsite backup. Throttling the cloud sync matters here — with multiple cameras recording continuously, an unthrottled upload would compete with the live streaming pipeline for the same limited bandwidth and CPU.
The full pipeline — multiple simultaneous camera streams, live HLS playback, local recording, and cloud backup — runs in under 1 GB of RAM in production on commodity hardware, with no transcoding at all. The core lesson: the expensive part of video infrastructure is almost always the encoding step, not the streaming itself. Avoid re-encoding when the source format is already good enough, and most of the "needs a powerful server" problem disappears.
I write about production systems, infrastructure, and cost optimization. See more case studies on my portfolio →