How to connect security alarms with the CCTV you already have

The default assumption when a site wants AI on its cameras is that the cameras will need replacing. Usually they do not. Most estates built over the last decade are already serving streams that are good enough for detection, and the real constraints turn out to be placement and light rather than the badge on the housing.

Working out which of your cameras can carry which events is a two-hour exercise. It is worth doing before you take a quote from anyone, including us.

Step 1: Get the actual camera list

Not the drawing from the original install. The current list, with four things per camera:

• Make, model and firmware — for the ones you can reach.
• What it points at, in plain words. “Back fence, east half.” “Goods door, from inside.”
• The stream it serves — resolution, frame rate, codec.
• Whether it is reachable over the network, and through what.

On most sites this list does not exist, and assembling it is the single most useful thing a security manager can do. It is also, reliably, where the surprises are: cameras that have been offline for months, cameras pointing at a wall after someone knocked them, cameras nobody can find credentials for.

Step 2: Check the stream, not the brand

A compatibility list organised by manufacturer is close to useless, because the same vendor ships cameras that work and cameras that do not. What matters is whether the camera serves a usable standard stream.

The practical baseline:

• RTSP or ONVIF. If the camera serves a standard stream, the brand is mostly irrelevant. If it only talks through a proprietary SDK, that is a project rather than a setting.
• H.264 or H.265. Both decode fine. MJPEG works but is wasteful for continuous analysis.
• Enough resolution at the distance that matters. This is the one people get wrong. A 4MP camera looking at a figure forty metres away across a dark yard has fewer usable pixels on that person than a 2MP camera ten metres away in light.
• A sub-stream. Useful, because continuous analysis on a sub-stream leaves the main stream untouched for recording.

Analog cameras need an encoder to produce an IP stream first. That is a hardware addition, and it should be priced as one.

Step 3: Work out what each camera can actually resolve

Here is the question that decides everything: at the distance where the event happens, how many pixels are on the person?

A rough way to check without instruments: pull up the live view, have someone stand where the event would occur, and look. Can you tell it is a person? Can you tell what they are doing? Could you recognise them? Those three thresholds are roughly the dividing lines between “detect”, “classify” and “identify”, and they decide which capabilities that camera can support.

Do it again after dark, with the lights as they normally are. Night is where most estates fall down, and the answer is nearly always lighting rather than a different camera.

Step 4: Decide where the processing runs

Two broad options.

On site. An appliance on your own network reads the streams and does the analysis locally. Video does not leave the building, bandwidth stays internal, and the system keeps working when the internet does not. This is the right default for most security deployments, and it is what regulated sites generally require.

In the cloud. Streams are uploaded for processing. Simpler to provision, but you are now paying for continuous upstream bandwidth per camera and your footage is leaving the site. For a handful of cameras this can be reasonable. For forty, the bandwidth arithmetic usually settles the question on its own.

Whichever you choose, ask what happens during an outage, and what is retained where.

Step 5: Keep the recorder

A point that causes unnecessary anxiety: adding analysis does not mean replacing your NVR or VMS. Reading a camera directly, or pulling a stream through the recorder, leaves the recorder doing exactly what it does now. Recording, retention and playback are unaffected.

If a vendor’s design requires ripping out your recorder, that is a commercial choice being presented as a technical one.

Step 6: Start with the events you are actually missing

The temptation is to enable everything. Resist it. Almost every site has two or three places where things genuinely go wrong — a back boundary, a goods door, a stockroom after hours. Those are worth instrumenting properly. The other thirty cameras can stay as they are until there is a reason.

A smaller deployment that produces a reviewable number of real events beats a comprehensive one that produces a queue nobody opens.

What the survey should tell you

A site survey worth having ends with answers to these, in writing:

• Which of my existing cameras can carry which capabilities, as they are today.
• Which ones need moving, relighting or relensing — and roughly what that costs.
• Which ones cannot be used for this, and why.
• What the event volume is likely to be per area.
• What hardware, if any, actually has to be bought.

If you get that, you can make a decision. If you get a quote without it, you are buying on assumption.