The Camera Already Solved Half of It

In one line: the camera is not a dumb sensor, and designs that treat it as one pay for work that was already done.

Three protocols, three jobs

Camera networking confuses people because three acronyms appear together and do different things.

ONVIF finds the camera and tells you what it can do. RTSP negotiates and controls a session, conventionally on TCP port 554. Only RTP moves video, usually over UDP with timestamps and sequence numbers so the receiver can reorder and detect loss.

There is a transport decision inside that. RTP over UDP is the default and loses packets gracefully — a corrupted frame or two, then recovery. RTP interleaved inside the RTSP TCP connection traverses firewalls and NAT far more reliably at the cost of head-of-line blocking. For a fleet spread across sites you will usually end up on interleaved TCP, because operations beats elegance when a camera sits behind someone else's router.

Two streams, and why that is a gift

Nearly every IP camera encodes the same sensor output twice and offers both simultaneously: a main stream at full resolution and bitrate, and a substream at something like CIF or 720p and a few hundred kilobits.

That is not a minor feature. It resolves a tension that would otherwise force transcoding into the architecture. Archive the main stream, because footage is only useful at full quality when someone finally needs it. Serve the substream for live monitoring, wall displays and mobile clients, because a person watching sixteen cameras on one screen cannot see 1080p detail anyway.

The saving is large and it costs nothing. A substream at 512 Kbps against a 4 Mbps main stream is roughly an eighth of the bits on the live path, and the camera produced it for free with hardware already dedicated to that purpose.

Where the video can be cut

This is the mechanism that propagates furthest, and the one most designs miss.

Compressed video is not a sequence of independent pictures. An I-frame is coded on its own. P- and B-frames are coded as differences against neighbours. A decoder that starts mid-sequence has nothing to difference against, so it cannot produce a picture.

The frame you can start from is an IDR frame — an instantaneous decoder refresh, which additionally tells the decoder to discard everything before it. The GOP, or group of pictures, is the span from one such frame to the next.

The consequence: a segment must begin at an IDR frame. You cannot cut a two-second segment out of a stream whose IDR frames arrive every ten seconds. The camera's keyframe interval is a hard floor on segment duration, and therefore on achievable live latency.

Cheap cameras commonly ship with a keyframe interval of 1× to 4× the frame rate — one or two seconds, which is fine. Some ship with intervals of thirty or sixty seconds to save bandwidth, which quietly makes low-latency live view impossible and forces either a camera reconfiguration or a transcoder.

The fix is almost always configuration, not architecture: set the keyframe interval to match your intended segment length, fleet-wide, via ONVIF. Being able to say that is worth a lot more than proposing a GPU tier.

Codecs, as a storage decision

Codec choice is a cost decision in this system, not a quality one.

The headline H.265 figure is "up to" 50%, and it is scene-dependent: heavy motion yields closer to 20% while a mostly static scene can exceed 50%. On a surveillance fleet — corridors, car parks, storage rooms — scenes skew static, so the savings land at the favourable end.

Smart codecs push this further by varying the GOP dynamically, lengthening the interval between I-frames when nothing is moving, with vendors claiming up to 70% reductions on quiet scenes. Note the tension with the previous section: a dynamically lengthening GOP is exactly the thing that makes segment boundaries unpredictable. Pick one.

One more capacity note. Constant bitrate makes the fleet's bandwidth and storage predictable, which is what you want when planning for a thousand cameras. Variable bitrate is more efficient but makes the aggregate a distribution rather than a number, and a car park at shift change can push every camera to its ceiling simultaneously. Plan capacity against the ceiling, not the average.

The camera as a buffer

Most cameras take an SD card, and most VMS platforms can use it. That turns the camera into the first stage of a store-and-forward pipeline.

When the uplink fails, the camera keeps recording locally instead of losing footage. When it recovers, the gap is backfilled. This converts a network outage from data loss into delayed data — a categorically better failure, and one that matters enormously for multi-site deployments where an uplink is a consumer-grade connection someone else maintains.

It changes the ingest contract too. The gateway must accept out-of-order arrival, because backfilled footage from Tuesday shows up on Thursday alongside live footage, and the index has to place it by capture time rather than arrival time.

Next: the ingest tier, and the strong argument for making it do as little as possible.