Can Existing Hikvision or Dahua Cameras Be Used for People Counting?
Search intent and context
Existing IP cameras can support selected counting scenarios through an external AI server or edge device if view angle, resolution, FPS and stream access are suitable.
Technology and analytics capabilities
RTSP/ONVIF can simplify integration, but a wall-mounted security view may have poor geometry for accurate retail footfall.
Limitations and field criteria
When small errors materially affect conversion KPIs, a dedicated 3D counter is often safer.
Procurement / integration decision
A pilot should measure manual-reference accuracy, peak versus quiet periods, direction errors, missed/false counts and data continuity after network interruptions.
Inventory is the first step in camera reuse
The question “we have 200 cameras, can we use them for people counting?” cannot be answered with a blanket yes or no. Position, resolution, codec, frame rate, lens, day/night conditions, RTSP access and person pixel size should be sampled because the same camera model can have very different analytics value in different views.
A practical inventory classifies cameras as ready for pilot, usable after a small view adjustment, or unsuitable without a dedicated sensor. That prevents a project from turning into an unnecessary full replacement.
Thinking about central AI server capacity
Central video analytics creates decode, inference and tracking load per stream. Running every 1080p stream at full frame rate is not always necessary; analytics FPS, resolution and regions of interest can be optimized by use case. GPU sizing should not be based on camera count alone.
Failover, maintenance windows and network bandwidth also matter. A server that opens fifty streams in a lab is not automatically a safe 24/7 production design for fifty streams.
Where existing CCTV can be a good fit
General occupancy trends, area flow, selected entry/exit analytics and other moderate-tolerance measurements can be cost-effective on an existing view when geometry is suitable.
Precision doorway footfall that feeds store conversion may justify a dedicated overhead counter. The objective is not to force one architecture onto every problem, but to match the measurement tolerance to the business use case.
Tie the proof of concept to acceptance criteria
Define success before the PoC: entry error tolerance, maximum data loss, latency, false positives and uptime. If criteria are invented after results arrive, stakeholders can interpret the same pilot differently.
A useful PoC produces both a technical feasibility result and a rollout cost model, giving the customer a decision document rather than just a demo.
The CS Otomasyon approach
For camera reuse, CS Otomasyon avoids both 'replace everything' and 'everything will work'. Cameras are classified by analytics suitability, representative sites are piloted, and entrances that genuinely require dedicated sensors are identified with evidence.
FAQ
Is every RTSP camera suitable?
No. Stream access enables integration; geometry and image quality determine analytics performance.
Can analog cameras be used?
Potentially through an encoder, subject to image-quality and latency validation.
Can an existing camera be repositioned?
Potentially, if physical constraints and the security use case allow it without losing required coverage.
Can enabling RTSP create security risk?
Yes if poorly configured; segmentation, authentication and access control should be applied.
How many stores should be in a PoC?
There is no fixed number; choose a small but diverse sample that represents the main geometry and traffic classes.
Conclusion and CTA
Choose the technology against the real entrance geometry and target KPI rather than the logo on the device. A site survey and controlled pilot with CS Otomasyon can validate the architecture before rollout and connect the resulting data to centralized reporting.