Local AI and cloud video: what belongs where?

Three decisions often get bundled together

A video system needs somewhere to process camera streams, somewhere to retain recordings and a way for authorized people to view them. Those functions do not all have to live in the same place. A system can analyze video on site, store recordings on a local device and still offer remote viewing.

Separating these decisions makes the tradeoffs easier to discuss. “Cloud camera system” can otherwise conceal important questions about what happens when the internet connection fails or how much continuous upload traffic is required.

Why bring processing closer to the cameras?

NIST’s fog-computing model describes distributing computing closer to connected devices in response to challenges including latency and scale. Applied to a camera system, local processing is an architectural option for reducing dependence on a round trip to a remote service.

It is not proof that any particular small computer can handle a particular number of cameras. Video decoding, detection, recording, live viewing and exports all compete for resources. The combined workload needs to be measured on the intended hardware.

Reference: NIST — Fog Computing Conceptual Model

Make the failure behavior explicit

Write down which functions should continue during an outage. Local recording and ordinary on-site review may be expected to remain available, while remote access or a cloud-only search function may be unavailable. The interface should show that distinction rather than suggesting everything is current.

Cloud storage also needs a clear policy. If an upload target is unavailable, the system needs a bounded local buffer, visible backlog information and a defined response when that buffer fills. No storage design can promise unlimited protection from an outage of unlimited length.

Compare choices using the same questions

The right conversation is about operational requirements. For each option, check who maintains it, how data is recovered and which costs grow with retention or traffic.

The BlackSight design

BlackSight’s proposed foundation uses on-site processing appliances with recording storage managed separately. The same intended viewing and control experience can be reached locally or remotely, with mobile clients also in the product plan.

Local, cloud and combined storage options are part of the design. The implementation must show truthful recording coverage and service health in each case. A diagram alone does not establish that recovery, offline access or cloud transfer is already working.

A useful first pilot

Choose two representative cameras and define a small set of checks: live view, recording, playback, an observable event and a controlled interruption. Record the hardware, software versions, camera settings and timing for each run.

This gives the next decision a real foundation. Expand only after the system has demonstrated the behavior the site needs, including what it does when a dependency is unavailable. That is the benefit we want BlackSight’s architecture to deliver: clear choices backed by evidence.