Why does the CCTV system choice affect AI analytics quality? AI video analytics systems process video feeds to detect events — intrusions, abandoned objects, crowd density changes, behaviour anomalies. The quality of the analytics depends as much on the camera system’s characteristics as on the AI model’s capability. Camera resolution, codec, frame rate, lens quality, and network architecture all affect what the AI model receives as input. The most common mistake is selecting cameras based on maximum resolution (4K, 8K) without considering the full pipeline. A 4K camera streaming H.265 at 15 FPS over a congested network produces lower analytics quality than a 1080p camera streaming H.264 at 30 FPS over a dedicated network — because the AI model needs consistent frame delivery more than it needs maximum pixel count. We see this pattern regularly: spec sheets win the purchasing argument, and the analytics layer inherits a feed that no model can rescue. The point of this article is narrower than a buyer’s guide. We are talking about the wired infrastructure decisions that determine whether an observable CV pipeline for CCTV has clean inputs to work with — because no amount of pipeline instrumentation downstream compensates for inconsistent capture upstream. What specifications matter for AI-ready CCTV? Specification Why it matters for AI Minimum for analytics Recommended Resolution Object detection accuracy 1080p (1920×1080) 2K–4K Frame rate Motion detection, tracking 15 FPS 25–30 FPS Codec Processing overhead, storage H.264 H.265 with H.264 fallback WDR (Wide Dynamic Range) Handles mixed lighting 100 dB 120+ dB IR illumination Night operation 30 m range 50 m+ range ONVIF compliance Integration with analytics Profile S Profile S + T Edge compute On-camera analytics Not required NVIDIA Jetson or equivalent ONVIF Profile S compliance is the integration anchor. Cameras that use proprietary streaming protocols force per-vendor adapter work for each ingestion pipeline — a cost multiplier that makes the system difficult to maintain and upgrade. Profile S covers basic video streaming; Profile T adds advanced streaming features including H.265 and metadata over the same connection. For a multi-vendor estate, treat Profile S as a hard requirement and Profile T as the default selection criterion. WDR is the specification most often skipped on the way to higher resolution numbers. In mixed-lighting environments — entrances, loading bays, anywhere the sun hits one side of the frame — a 4K camera without adequate WDR produces frames where half the scene is crushed black and the other half is blown white. A detection model trained on balanced exposure has no signal to work with in either region. WDR rated at 120 dB or above keeps both the bright and dark sides of the frame within the dynamic range the model was trained on. How should the network architecture support AI analytics? Wired CCTV uses either analogue (coax) or IP (Ethernet) infrastructure. For AI video analytics, IP is required — analogue systems must be digitised at the encoder before any model can process them, adding latency and a failure point. The network architecture for an AI-ready installation has three load-bearing decisions. Dedicated VLAN. Video traffic should be isolated on its own network segment to prevent bandwidth contention. A single 4K camera at 30 FPS generates 8–25 Mbps depending on codec and scene complexity (observed range, not a benchmarked rate — scene motion dominates the figure). Twenty cameras generate 160–500 Mbps sustained, enough to saturate a shared network segment and produce intermittent frame drops that look like model errors when they are actually transport errors. PoE+ (Power over Ethernet Plus). Delivers up to 30 W per port over the network cable, eliminating separate power runs. Sufficient for most IP cameras including those with IR illumination and heated housings. For cameras with onboard compute (NVIDIA Jetson-class edge inference), check whether PoE++ (60 W) is required — the analytics workload pushes some camera platforms past the PoE+ ceiling. Edge processing versus centralised. In our deployments we favour edge processing for latency-sensitive applications (real-time alerts, gate triggers) and centralised processing on a GPU server for throughput-sensitive applications (post-event search, behaviour analysis across multiple cameras, cross-camera tracking). Edge keeps the alert loop short; centralised gives the model the broader context. Most production estates use both, with the partition decided per camera role rather than per system. For the detection-tuning methodology that sits on top of this split, our analysis of surveillance false-alarm patterns and detection thresholds covers the per-zone tuning approach. What should you prioritise when selecting a system? For a new AI analytics deployment, the prioritisation that survives contact with operations is: ONVIF compliance and standard codec support over proprietary features. Standards survive vendor changes; bespoke SDKs do not. WDR capability over maximum resolution. Most analytics failures come from lighting, not pixel count. 25+ FPS sustained frame rate over peak burst frame rate. Spec sheets list peaks; trackers need sustained. Network headroom. Aggregate bandwidth across all cameras simultaneously, with at least 30% headroom for future expansion. Plan for the worst-case scene (high motion, complex backgrounds) on every camera at once, not the average case. These four hold whether the analytics stack runs on Jetson at the edge, on a GPU server with TensorRT-optimised models, or on a hybrid pipeline using ONNX Runtime for portability across both. The infrastructure decisions are model-independent; the model decisions are not infrastructure-independent. How do you future-proof a CCTV installation for AI analytics? Cameras installed today will likely serve for 5–10 years. The analytics capabilities available in 5 years will exceed today’s capabilities — anyone who has watched detection model accuracy improve year on year can extrapolate. Future-proofing the camera infrastructure means installing hardware that can support analytics capabilities that do not yet exist, because the cable runs and mounting decisions are far more expensive to change than the model is. The choices that age well: Install cameras with higher resolution than currently needed (2K minimum, 4K preferred). Future models may extract value from resolution that current models cannot fully utilise — fine-grained classification, small-object detection at distance, sub-pixel motion analysis. Ensure all cameras support H.265 and have headroom for AV1 or future codec standards. Codec efficiency directly determines how many cameras a fixed bandwidth budget supports. Install network infrastructure with 2–3× the bandwidth currently required. Cat6A or fibre during initial installation costs marginally more than Cat6 but supports 10 Gbps per run — sufficient for 8K cameras and edge compute requiring high-bandwidth backhaul. Choose cameras with edge compute capability or expansion options, even if edge analytics are not planned at launch. Retrofitting edge compute is a per-camera site visit; specifying it once is a procurement line item. Cable infrastructure is the most expensive component to upgrade after installation. We have seen installations where the cost of re-cabling exceeded the cost of the original camera system — an avoidable outcome that traces back to a Cat6 decision made years earlier when the bandwidth difference looked academic. How should storage planning differ for AI analytics? Traditional CCTV storage retains full video for 14–30 days then deletes. AI analytics changes the retention model because the system now produces structured outputs alongside raw video, and those outputs have different retention requirements. A tiered architecture aligns storage cost with retention value: Tier Content Typical retention Storage class Hot Full video, all cameras 14–30 days NVMe / fast SATA Warm Detection events with associated clips 1–3 years (compliance-driven) Bulk HDD Cold Annotated training frames, ground-truth datasets Indefinite Object storage / archive This tiered approach typically reduces storage cost compared to retaining full video at the longest retention requirement (observed pattern across our surveillance engagements; the exact reduction depends on event density and compliance horizon). The trap to avoid is treating training data as a hot-tier artifact — annotated frames are small per item but accumulate indefinitely, and they belong on cheap object storage with appropriate metadata, not on the same disks serving live retrieval. Storage planning that projects requirements from camera count, resolution, retention policy, and expected detection-event frequency prevents the common failure mode: running out of storage six months into deployment and being forced to either reduce retention or add emergency capacity at premium cost. The projection should be revisited whenever a new camera is added or a new detection class is enabled — both change the storage curve. FAQ
