Retrofitting Analytics Onto CCTV You Already Have

Analytics needs a video stream it can read, enough pixels on the subject to work with, and somewhere to run. An existing estate usually satisfies that for most of its cameras and fails for a few, and the few are worth identifying before the project rather than during it. What follows is the survey, ordered by what stops a deployment earliest.

The blocking questions, in order

Can you get the stream at all?

Everything depends on this. Most IP cameras expose an RTSP stream, and if yours do, the rest is engineering. The estates that cannot be retrofitted are the closed ones: a proprietary recorder that will only talk to its own client software, cameras locked to a manufacturer cloud, or firmware with the stream endpoint disabled and no credentials on record. Establish this on day one for a sample of each camera model you own, because a "no" here changes the project into a replacement.

Older analogue cameras are not a dead end — an encoder converts them — but they cap resolution at what the original signal carried, which usually rules out anything requiring detail.

Are there enough pixels on the subject?

Camera resolution is the number quoted and it is the wrong number. What matters is pixel density on the thing you care about: a 4K camera covering a whole yard may put fewer pixels on a person at the fence than a 1080p camera aimed at that fence. Detecting that a person is present needs relatively little. Determining whether they are wearing a helmet needs considerably more, and reading a plate more again.

The practical test is to pull a still from the live stream at the distance that matters and look at the subject. If you cannot tell what you are asking the model to tell you, no model will do better from the same frame.

What is the frame rate and codec?

Presence and PPE checks are tolerant of low frame rates; counting and tracking are not, because they need to follow a subject between frames. Estates configured for cheap storage sometimes run a few frames per second, which is fine for review and insufficient for tracking. Codec matters mainly for decode cost — H.265 halves bandwidth and costs more CPU to decode, which changes how many streams one box handles.

Will the network and power carry it?

Pulling a second stream per camera for analytics roughly doubles that camera's network load. On a switch that was specified for the original estate with no headroom, this is a real constraint, and it shows up as dropped frames rather than an outage — which is harder to diagnose. If cameras need adding or repositioning, PoE budget on the switch and spare capacity in the cabinet matter as much as the camera cost.

The two commercial traps

The first is licensing. Some recorders limit concurrent stream subscribers, or license analytics per channel, or void support if a third party consumes the stream. None of that is a technical barrier and all of it is a cost, and it is better discovered before a proof-of-concept than after a successful one.

The second is the manufacturer's own analytics, already paid for and often unused. Many cameras include on-board detection, and for simple zone alerts it can be adequate. It is worth checking before buying a layer on top — though the usual reasons it is not enough are real: rules configured per camera with no central view, no cross-site reporting, and detection quality that varies by model and firmware age.