Cameras
Face Matcher processes live video from many parallel sources in real time, continuously from the moment a source is enabled until it is disabled, and publishes an event for everything it finds. Before choosing camera hardware you decide where the video is processed: on the server, or on the device. Both paths are fully supported and can be mixed in one deployment.
Video sources
| Source | Registered as | Requirement |
|---|---|---|
| IP camera | Camera | Must provide an RTSP stream (H.264 or MPEG-4). |
| Video management system (VMS) or network video recorder (NVR) | Camera | Must re-publish the camera as an RTSP stream. |
| Smart camera or AI box | Edge stream | Must run the Embedded Stream Processor and reach the MQTT broker. |
| USB or laptop camera, looped video file | Camera | Demonstrations only, not for production. |
Each physical source is registered individually, either in Station or through the REST API: ten IP cameras mean ten Camera entities. A Camera is a source processed on the server; each one runs in its own cam-* container. An Edge stream is a source processed on the device; all edge streams share the single edge-stream-processor service.
| Camera (server-side) | Edge stream | |
|---|---|---|
| Video decoding | on the server | on the device |
| Input to Face Matcher | video stream | metadata (face crops, templates, results) |
| Processing | one container per source | one shared service |
| Network load per source | full video stream (about 4 Mbps) | small MQTT messages |
| Hardware freedom | any RTSP camera | supported devices only |
The pipeline is the same
Whichever path you choose, the frames pass through the same stages: decoding, detection, tracking, extraction, matching and optionally liveness. With server processing all of them run in Face Matcher. With edge processing the Embedded Stream Processor runs the first stages on the device and hands the results to Face Matcher over MQTT; how many stages move to the edge depends on the device's capability.
| Stage | High-end edge device | Low-performance smart camera |
|---|---|---|
| Video decoding | on device | on device |
| Face detection | on device | on device |
| Tracking | on device | on device |
| Template extraction | on device | on server |
| Matching | on device | on server |
| Liveness | on device | on server |
Only face-related stages can run on the edge; pedestrian and object detection are server-side features.
Which path to choose
Server-side RTSP is the safe default: any RTSP camera works, cameras are interchangeable, and everything is tuned centrally. Its cost grows linearly with the number of streams in bandwidth and server CPU or GPU. Edge processing cuts both, lowers latency and scales to many cameras on modest servers, at the price of a narrower hardware list and per-device configuration. Read the two source-type pages, then use the selection criteria to pick hardware that performs in the field:
- Server-side RTSP processing — classic IP cameras, all compute on the server.
- Edge streams — smart cameras and AI boxes running the Embedded Stream Processor.
- Choosing a camera — optics, lighting, mounting and networking criteria.
Registering and configuring sources in the UI is covered in the Station pages for cameras and edge streams.
Server-side RTSP
In this model the camera is a plain IP camera: it captures video and publishes an RTSP stream, nothing more. Face Matcher pulls that stream and does all the work on the server: decoding, face detection, tracking, template extraction, watchlist matching and, if enabled, liveness. The camera never knows it is part of a biometric system, which keeps the device side simple and interchangeable. Any camera, VMS or NVR that publishes RTSP in H.264 or MPEG-4 can be used; swapping a faulty camera for a different model needs no change beyond the stream URL.
One container per stream
Each registered Camera is processed by its own camera service. The release package ships five slots, cam-1 to cam-5 (CameraServicesCount=5 in .env), plus the cam-nx slot. Registering a camera in Station or through POST /api/v1/Cameras assigns it to a free slot; the camera's settings (RTSP URL, detector resource IDs, thresholds, save strategies, preview) belong to the Camera entity, not to the container, so they survive restarts and upgrades. To process more streams than there are slots, add camera services and publish their preview ports; the Scaling guide shows how.
Decoding with GStreamer
The camera service decodes the stream with a GStreamer pipeline built from the GstPipelineTemplate setting in .env. The default {0} lets the service build a standard software pipeline from the RTSP URL. For hardware-accelerated decoding on NVIDIA GPUs or Jetson boards, replace the template with the commented examples shipped in .env (they use nvvideoconvert or nvvidconv) and enable the GPU on the camera services, see the GPU acceleration guide.
GstPipelineTemplate={0}
Detection for a server-side camera runs either inside the camera service or in the dedicated detector service, depending on the camera's face detector resource ID; the options are explained in Detection and matching settings.
Live previews
Every camera service can serve a live preview with bounding boxes for Station. Previews are published on host ports 30001 – 30005: the port is 30000 plus the camera's sequence number, unless you fix one with CameraDefaults__PreviewPort. The preview is a convenience that costs CPU; lower its quality or disable it (mpeG1PreviewEnabled: false) on cameras nobody watches. For an annotated preview meant for external displays see Enhanced preview.
Sizing and network
Every camera sends a full video stream across the network and consumes server CPU or GPU, so cost grows with each camera added. Plan for roughly 4 Mbps of stable bandwidth per camera and size the server so that every stream is processed at 15 fps or better; if the network cannot guarantee that, edge streams are usually the better fit. Hardware figures per camera count are in Hardware requirements.
When to choose it
Choose server-side processing 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, follow Cameras in Station; RTSP URL formats and privacy masking are covered in RTSP URLs and masking.
Edge streams
An edge stream is a video source processed on the device itself. A smart camera or an AI box runs the Embedded Stream Processor, which decodes the video, detects and tracks faces and, on capable hardware, also extracts templates, matches them against a locally synchronized watchlist and checks liveness. Instead of shipping raw video, the device sends only the results, so bandwidth and server load per camera drop dramatically and latency improves. This is what makes edge processing attractive as a site grows from a few cameras to dozens.
How the device talks to Face Matcher
The Embedded Stream Processor publishes FrameData messages over MQTT to the RabbitMQ broker of the deployment (rmq:1883 inside the network, host port 1883). A FrameData message carries the face crop, the tracklet information and, depending on the device, the face template, the identification result and the liveness result. RabbitMQ forwards MQTT messages into a queue that the edge-stream-processor service consumes; the defaults in .env are:
EdgeStreamRmqConsumer__ExchangeName=amq.topic
EdgeStreamRmqConsumer__QueueName=MQTT_EDGE_STREAM_CONSUMER
EdgeStreamRmqConsumer__RoutingKey=edge-stream.*.frame_data
One edge-stream-processor service serves all edge streams. It completes whatever the device did not do (extraction if no template was sent, matching, liveness), generates the same events as a server-side camera and stores data according to the edge stream's save strategies. In the other direction, the edge-streams-state-synchronizer service pushes watchlist members to the devices over MQTT so that they can identify people locally; see the edge watchlist sync guide.
Server or device: who decides
Two strategies on the edge stream entity control whose results count:
| Strategy | EdgeStreamOnly | ServerOnly |
|---|---|---|
| Matching | Face Matcher trusts the identification made on the device, fetches the member's business data (name, watchlist) and drops the result if the score is below the watchlist threshold or the member is unknown. When the device returns several candidates, the best score wins. | Face Matcher ignores the device's identification and matches the template itself with the matcher service. |
| Liveness | Face Matcher uses the liveness result computed on the device for the liveness types enabled through the API; server-side condition strings are ignored. Missing data means NotPerformed. | Face Matcher ignores the device's liveness result and runs its own check; the device must send a face crop with a face area of at least 5. |
If a template is missing from FrameData, or was produced by an algorithm version the server does not use, the server extracts it again (FrameDataProcessing__ForceExtractionOfIncompatibleFaceTemplates forces re-extraction even for compatible templates).
Hardware
Edge processing depends on the device, so the hardware list is narrower than for RTSP: smart cameras built on the Ambarella SoC and AI boxes with Hailo-8 accelerators or NVIDIA Jetson modules. The tested models are listed in Supported devices; confirm a model is on the list before purchasing. The Embedded Stream Processor is delivered with the Embedded Toolkit, a separate product documented under Embedded biometrics.
When to choose it
Choose edge streams when you are scaling to many cameras, your network or server budget is constrained, or you need the lowest possible latency. The trade-offs are less vendor freedom and per-device installation and licensing. Installing the processor and pointing it at the broker is described in the Stream Processor manual; registering the stream and configuring it centrally is described in Edge streams in Station.
Choosing a camera
Once you have picked a source type, the camera optics, lighting, mounting and network decide whether recognition works in practice. The selection criteria and the site-survey method, with example images, are in the Camera selection and placement guide.
Compatible hardware
For server-side RTSP, any camera, VMS or NVR streaming H.264 or MPEG-4 works. For edge streams, use a device from Supported devices (Ambarella-based smart cameras, or AI boxes using Hailo-8 or NVIDIA Jetson). Pricing and availability vary by market, so research current options and share any shortlist with Innovatrics for a compatibility check.