Server-side RTSP processing

In this model the camera is a plain IP camera: it captures video and publishes an RTSP stream, nothing more. The server consumes that stream and the Video Processing Platform does all the heavy lifting — face detection, template extraction, and watchlist matching all happen server-side. The camera never knows it is part of a biometric system, which keeps the device side simple and interchangeable.

The platform can technically process any IP camera capable of RTSP streaming encoded in H.264 or MPEG-4, which covers the vast majority of cameras on the market. You register the stream URL once and the server connects to it immediately; swapping a faulty camera for another RTSP model needs no change beyond the stream URL. This vendor independence is one of the main reasons RTSP stays popular.

The trade-off is server load and network bandwidth. Every camera sends a full video stream across the network and consumes server CPU/GPU for processing, so cost grows with each camera added. Plan for roughly 4 Mbps per camera of stable bandwidth and size the server to keep every stream above 15 fps; if the network cannot guarantee that headroom, on-edge processing is usually the better fit.

Choose this approach when you want maximum freedom in camera selection, already run reliable network and server infrastructure, or operate a modest number of cameras where central compute is not a bottleneck. To register a stream once you have chosen hardware, see Add Cameras.