HLS vs. WebRTC: The Engineering Logic Behind SourceBox Sentinel's Streaming Architecture
By S’Bussiso Dube/SourceBox Team
In the world of professional security and local-first surveillance, every engineering decision is a tradeoff. One of the most critical and most debated decisions in building a video system is the choice of streaming protocol. How does the video actually get from the camera to your eyes?
Most marketing pages avoid this conversation. They use buzzwords like "Instant" or "Real-time" to hide the plumbing. But at SourceBox, we believe that Professional Grade isn't a marketing claim; it is the residue of a hundred small engineering decisions made correctly.
Today, we are opening the hood of SourceBox Sentinel to explain why we chose HLS (HTTP Live Streaming) over the industry-standard WebRTC, and why this choice is fundamental to our mission of digital sovereignty.
The Contenders: Real-Time Speed vs. Sovereign Reliability
To understand the engineering choice behind Sentinel, we first have to define the two opposing philosophies of video transport. In the streaming world, you generally have two paths: a persistent connection (WebRTC) or a segmented delivery (HLS). While both get video from point A to point B, they do so using entirely different mechanical logic.
WebRTC: The Sprint for Zero Latency
WebRTC (Web Real-Time Communication) is the protocol that powers Zoom calls and Google Meet. It is designed for one thing: speed. It establishes a persistent, peer-to-peer connection that pushes media with sub-second latency.
The Wins: Glass-to-glass latency is typically under half a second. If you are steering a remote-controlled drone or engaging in a live video call, WebRTC is the only option.
The Hidden Costs: WebRTC is "stateful." Every single viewer requires a live, open connection to the server. This creates a massive scaling problem. To handle multiple viewers, you need a complex media server (an SFU). Furthermore, WebRTC struggles with home routers; it requires a complex system of STUN/TURN servers and NAT traversal to punch through firewalls.
HLS: The Standard for Reliable Delivery
HLS (HTTP Live Streaming) takes a different approach. Instead of one long, fragile stream, HLS chops the video into small, discrete segments (usually 1-2 seconds long) listed in a rolling playlist.
The Wins: HLS is "stateless." It uses plain HTTPS—the same protocol used to load a webpage. It traverses firewalls and NATs for free, it is easily cacheable, and it scales trivially across any network. Most importantly, each segment is already a recordable unit of video.
The Costs: Latency. Because the client must download a few segments before playing, HLS runs a few seconds behind "live" time.
If the only metric were speed, the choice would be simple: WebRTC wins. But for a local-first security system, "speed" is a deceptive metric. The right questions are: What are my actual needs and what am I trying to accomplish?
Why HLS is the Correct Choice for SourceBox Sentinel
Sentinel is not a video-calling app, it’s a private security system. It’s easy to be blinded by latency numbers. In a spec sheet, "sub-second" always looks better than "a few seconds." But a security system is not a Zoom call; it is a vault for your visual history.
We designed Sentinel to be a "Zero-Config" experience, meaning it should work the moment you plug it in, regardless of how complex your home network is. To achieve this, we identified three non-negotiable architectural requirements that prioritize reliability and sovereignty over raw speed. When those requirements are the priority, HLS is the only protocol that delivers.
Unified Pipeline: Live and Recording are One
In most security systems, "Live View" and "Recording" are two different systems. The live stream goes to terms of service, and a separate encoder writes the file to the disk. This adds complexity, increases CPU load, and creates more points of failure.
In Sentinel, the live stream IS the recording. Our Camera Nodes encode video into HLS segments using FFmpeg. Those exact segments do double duty: they are streamed to your browser for live viewing, and they are simultaneously archived to your encrypted local disk (AES-256-GCM).
By using HLS, we eliminate the need for a second encoder. Your storage and your stream are the same bytes. This ensures that what you see in the live view is exactly what is saved to your vault.
Zero-Config Networking and the "Push" Model
One of the biggest pain points in self-hosting is "Port Forwarding." Most users don't want to risk their security by opening holes in their firewall.
Because HLS uses plain HTTPS, Sentinel can use an outbound push model. The CloudNode pushes segments outbound to the Command Center. There are no inbound connections required to your home network. No VPN, no static IP, and no STUN/TURN relays. This allows Sentinel to be "plug-and-play" while remaining completely secure. WebRTC would require a complex set of relays to achieve the same result, adding layers of third-party dependency that we refuse to accept.
The "Stateless Window" Concept
We believe that the cloud should be a window, not a warehouse.
The Sentinel Command Center does not store your footage; it only serves it. It keeps a short, rolling buffer of recent HLS segments in memory which is typically about 60 seconds. When you open your dashboard, you are simply reading a cache.
Because HLS is stateless, we can serve thousands of tenants from a modest cloud infrastructure without holding a live, resource-heavy peer connection open for every single user. This efficiency allows us to keep the service stable and the costs low, all while ensuring the actual data never leaves your hardware.
The Honest Trade-off: Addressing the Latency Gap
We will not dress this up: Sentinel's live view runs a few seconds behind real-time. If you are looking for sub-second latency, WebRTC is the superior tool.
However, we believe this is a a-negligible trade-off for a security use case. Security monitoring is not "interactive control." You are not steering a drone or performing remote surgery; you are confirming a delivery, checking a workshop, or monitoring a perimeter. A two-to-five-second offset on a feed that is reliable, encrypted, and reachable from anywhere is a professional trade-off, not a corner that was cut.
The amateur move is to chase the lowest latency number on a spec sheet. The professional move is to identify which metric actually impacts the mission. For Sentinel, that metric is reliability and recording integrity.
The Roadmap: Localized Low-Latency
The choice of HLS does not mean we ignore latency. In fact, it allows us to implement a tiered approach to streaming.
There is one scenario where the latency trade flips: LAN-Direct viewing. When you are standing in the same building as your Camera Node, you don't need the cloud window. Sentinel already supports LAN-direct paths for integrations like Home Assistant.
Layering a low-latency WebRTC path onto that local link is a natural future enhancement. This gives the user the best of both worlds: Stateless HLS for global remote access, and Instant WebRTC for local monitoring.
The Verdict: Reliability Over Milliseconds
WebRTC wins on latency. HLS wins on every metric that defines a sovereign security system: recording alignment, zero-config networking, stateless scalability, and data ownership.
By choosing HLS, we have ensured that SourceBox Sentinel is a system that just works, regardless of your network complexity. We've prioritized the integrity of your recordings over a few milliseconds of lag.
The streaming protocol is the part of the product you're never supposed to notice. Ours is the one we chose on purpose.
Stop renting your digital existence.
Buy a board, spin up a container, take your data back.
