Structuring the Middle of the Pipeline Edge filtering, the subject of the last post, doesn't eliminate central processing. It shrinks it and makes it more meaningful. You still need recording, cross-camera correlation, alert enrichment, and any detection work the edge tier couldn't handle on its own. That work has to live
Crowd Counting and Environmental Hazard Detection Every edge CV category covered so far in this arc cares about an individual. Which person is this, which plate is that, which two actors interacted, which specific sequence of steps just ran. Crowd counting and environmental hazard detection don't. They care about an aggregate state: how many
Beyond Detection: Activity Understanding Object detection answers one question: what is in this frame. A person, a car, a hard hat, a face. That question is now cheap to answer. Earlier posts in this arc covered detection running directly on camera hardware, recognition models identifying specific people and plates, and re-identification tracking the
Following Someone Across Cameras Every use case in this arc so far has had a clean answer. Recognition earns edge processing because the payload is time-sensitive and legally sensitive at once. PPE and weapon detection require continuous local inference because the alternative defeats the point entirely. Multi-camera re-identification is the one
Safety and Compliance at the Edge PPE compliance monitoring and weapon detection sit in a different category from everything else in this arc, and I want to be direct about why before getting into either one. Recognition, which I covered in the last post, benefits from edge processing. PPE and weapon detection require it. There'
Recognition at the Edge Post 15 laid out the general pattern for edge CV: detect locally, forward only what matters, keep the central pipeline focused on events. Raw frames stay put. That pattern answers one question. Is there something here worth attention. A car in the lot. A person near a restricted door. A
Processing at the Edge A few posts back, I mentioned that computer vision hooks are one of the main reasons teams reach for a heavyweight pipeline framework like Kurento in the first place. You want to detect something in the stream, so you build a place in your architecture for that detection to happen.
Thundering Herd: What Breaks When Everyone Looks at Once A motion alert fires. In the next few seconds, every person watching that camera's feed, plus everyone who just got a push notification about it, opens the stream at once. That's a thundering herd, and it is not the same load pattern as the slow, steady
Load Testing WebRTC at Scale: The Two Axes Most Test Plans Miss Most WebRTC load tests answer a question nobody asked. They ramp up a connection count, watch CPU and bandwidth climb together, declare a ceiling, and call it capacity planning. The number they produce is real. It's also almost useless, because it collapses two independent stress patterns into one
Failover in Live Video Failover in live video is a real design decision with a real tradeoff. Most teams don't treat it that way. They build whichever option is easier to ship first, call it done, and only discover they made a decision at all when an instance dies during exactly the
Sharding Streams at Scale Shard by stream, not by viewer. That single rule decides how the rest of your fan-out architecture behaves once you're running more source streams than one instance can hold, and it's the rule I see teams get backwards most often. Here's the model.
Migrating Off a Legacy Media Server Swapping a media server platform is a real migration project. It is not a config change, and it is not a library version bump. I've watched teams walk into this thinking it's the second thing when it's actually the first, and the gap between
Matching the Tool to the Workload There is no single best media server. I've now walked through five of them across three posts, and if you take one thing away from this run, take this: every one of those tools is the right answer to a specific question, and a weak answer to almost
LiveKit vs mediasoup The last post ruled out a full pipeline framework for any team whose job is fan-out, not in-flight processing. That leaves a lean SFU, and picking one comes down to two names: LiveKit and mediasoup. I'll give you the recommendation up front and spend the rest
Kurento and the Pipeline Approach Most teams building one-to-many live video reach for a media server and assume they need the most capable one they can find. That instinct is backwards. The right question is narrower: does anything need to touch the media while it's in flight, or does it just
The Gateway Layer: Getting RTSP Cameras Onto WebRTC Every one-to-many live video system that starts with IP cameras needs a layer between the camera and whichever SFU handles fan-out to viewers. That layer's job is narrow: take RTSP in, put WebRTC out, and do it without adding latency or CPU cost you didn&
Keyframes and Latency: The Cheapest Win Most Teams Never Touch Glass-to-glass latency is the number that actually matters. It's the total delay from a photon hitting the camera sensor to a pixel appearing on the viewer's screen, and it's the only measurement that captures what a user actually experiences. Not the network
Stop Transcoding: The Biggest Lever in an RTSP-to-WebRTC Pipeline If your RTSP-to-WebRTC pipeline is burning CPU, the fix usually isn't a faster transcoder. It's no transcoder at all. That sounds too simple to be the headline of a post, but I've watched enough teams throw hardware at this problem to know
The TURN Tax: WebRTC's Hidden Cost Center Every cost model I've seen for a WebRTC media platform starts in the same place: SFU capacity, egress bandwidth per viewer, maybe some CPU headroom for encoding. Almost none of them start with the line item that actually blows the budget in production. That line item is TURN
Split the Control Plane From the Data Plane, or Neither Will Scale Here's a decision that looks small on a whiteboard and turns out to be load-bearing for everything downstream: split the control plane from the data plane. Do it early, do it deliberately, and most of your scaling problems later in this series become tractable. Skip it, and
Choosing a Video Topology That Scales If you're building anything that streams live video from a small number of sources to a large number of viewers, the first architectural decision you make determines whether the rest of the system is easy or miserable. That decision is the video topology: how streams get from cameras
Governance as the Control Plane for AI Most AI governance programs fail for the same reason data governance did: policy documents can't see, stop, or catch violations. Runtime governance requires a catalog-based control plane that enforces at machine speed, not a binder nobody reads.
The Twelve Problems of Agentic Software Delivery Agentic software delivery breaks down into twelve interlocking problems across four layers. Skip one and the failure doesn't stay put — it surfaces as a symptom in a completely different layer downstream.
The Architecture of Enterprise AI Retrieval Naive enterprise RAG fails in five specific, nameable ways: permissions, authority, oversaturation, time, and structure. Here's the corrected retrieval architecture that fixes each one as a distinct gate.
Engineering Reliability into Autonomous AI Agents A ten-step pipeline at 95% accuracy per step is only 60% reliable end to end. The fix is architecture: six defensive layers, a seven-phase recovery pipeline, a ratchet on quality gates, and why one agent can't hold the whole system.
