Architecture

Though you mostly interact with FindFace Multi through its web interface, be sure to take a minute to learn the FindFace Multi architecture. This knowledge is essential for the FindFace Multi deployment, integration, maintenance, and troubleshooting.

In this chapter:

Recognition Objects and Recognition Process
Architectural Elements
Single- and Multi-Host Deployment
CPU- and GPU-acceleration

Recognition Objects and Recognition Process 

FindFace Multi can recognize the following objects and their features:

human faces
human bodies (silhouettes)
cars

Note

The face recognition functionality is enabled by default. Make changes to configuration files to enable the body and car recognition.

FindFace Multi detects an object in the photo or video and prepares its image through normalization. The normalized image is then used for extracting the object’s feature vector (an n-dimensional vector of numerical features that represent the object). Object feature vectors are stored in the database and further used for verification and identification purposes.

Architectural Elements 

FindFace Multi consists of the following fundamental architectural elements:

FindFace Core, a cutting-edge AI-based recognition technology that can be used as a separate product FindFace Enterprise Server.
FindFace Multi, which is a turnkey application module for FindFace Enterprise Server.

The FindFace Core internal architecture allows for embedding Video Recorder, an additional functionality that records, stores, and plays back video data from cameras.

Architecture scheme 

architecture_en

FindFace Core 

The FindFace Core includes the following components:

Component	Ports in use	Description	Vendor
findface-extraction-api	18666	Service that uses neural networks to detect an object in an image and extract its feature vector. It also recognizes object attributes (for example, gender, age, emotions, beard, glasses, face mask - for face objects). CPU- or GPU-acceleration.	NtechLab own deployment
findface-sf-api	18411	Service that implements the internal HTTP API for object detection and recognition.
findface-tarantool-server	32001, shard ports (default 330xx, 81xx)	Service that provides interaction between the `findface-sf-api` service and the feature vector database (the Tarantool-powered database that stores object feature vectors.
findface-upload	3333	NginX-based web server used as a storage for original images, thumbnails, and normalized object images. If Video Recorder is installed, `findface-upload` also stores video data from cameras.
findface-facerouter	18820	Service used to define processing directives for detected objects. In FindFace Multi, its functions are performed by `findface-security` (see FindFace Multi Application Module). If necessary, you can still deploy and enable this component for integration purposes (see findface-facerouter and Custom Plugins).
findface-video-manager	18810, 18811	Service, part of the video object detection module, that is used for managing the video object detection functionality, configuring the video object detector settings and specifying the list of to-be-processed video streams.
findface-video-worker	18999	Service, part of the video object detection module, that recognizes an object in the video and posts its normalized image, full frame and metadata (such as detection time) to the `findface-facerouter` service for further processing according to given directives. If Video Recorder is enabled, `findface-video-worker` sends video over to `findface-video-storage`. Provides face liveness detection if enabled. CPU- or GPU-acceleration.
findface-ntls	443 (TCP), 3133, 3185	License server that interfaces with the NtechLab Global License Server, a USB dongle, or hardware fingerprint to verify the license of your FindFace Multi instance.
findface-counter	18300	Service used for event deduplication.
findface-liveness-api	18301	Besides the embedded functionality provided by `findface-video-worker`, face liveness detection can also be harnessed as a standalone service `findface-liveness-api`. The service takes a specific number of frames from a video chunk and returns the best quality face, and decimal liveness result averaged across the taken frames (see Liveness Detection as Standalone Service). The service is also involved in the course of user authentication by face.
Tarantool	Shard ports (default 330xx, 81xx)	Third-party software that implements the feature vector database that stores extracted object feature vectors and identification events. The system data, cards, user accounts, and camera settings are stored in PostgreSQL (part of the FindFace Multi application module).	Tarantool
etcd	2379	Third-party software that implements a distributed key-value store for `findface-video-manager`. Used as a coordination service in the distributed system, providing the video object detector with fault tolerance.	etcd
NginX	80; SSL: 8002, 8003, 443, 80	Third-party software that implements the system web interfaces.	nginx
memcached	11211	Third-party software that implements a distributed memory caching system. Used by `findface-sf-api` as a temporary storage for extracted object feature vectors before they are written to the feature vector database powered by Tarantool.	memcached

FindFace Multi Application Module 

The FindFace Multi application module includes the following components:

Component	Ports in use	Description	Vendor
findface-security	Configurable	Component that serves as a gateway to the FindFace Core. Provides interaction between the FindFace Core and the web interface, the system functioning as a whole, HTTP and web socket, object monitoring, event notifications, episodes, webhooks, object clusterization, and counters. Includes the following internal services: NTLS checker, Counter manager, Webhooks manager, Clusterizator, Event episodes manager, and Video archive queue manager. The last four can be enabled and disabled via the `/etc/findface-security/config.py` configuration file.	NtechLab own deployment NATS
findface-security-ui	Configurable	Main web interface used to interact with FindFace Multi. Based on the Django framework. Allows you to work with object recognition events, search for objects, manage cameras, users, cards, watch lists, collect real-time statistics, and many more.
NATS	4222	Third-party software that implements a message broker inside `findface-security`.
etcd	2379	Third-party software that implements locks in the `findface-security` service, such as locks in NTLS checker, reports, video processing, object clusterization, etc.	etcd
Pgbouncer	5439	Third-party software, a lightweight connection pooler for PostgreSQL. Optional, used to increase the database performance under high load.	PgBouncer
PostgreSQL	5432	Third-party software that implements the main system database. This database stores cards of persons and cars and data for internal use, including user accounts and camera settings. The object feature vectors and object identification events are stored in Tarantool (part of the FindFace Core).	PostgreSQL

Video Recorder 

Video Recorder is an optional part of the FindFace Core. It includes the following components:

Component	Ports in use	Description	Vendor
findface-video-storage	18611	Service that implements video chunk management. It takes video chunks from the `findface-video-worker` component, puts them into the storage (`findface-upload`), and writes their meta-information and whereabouts to the Video Recorder database (MongoDB). By request from `findface-security`, it issues info about existing video chunks in the form of Websocket-links to the corresponding streams. These links are further used by `findface-video-streamer-cpu` to deliver the video to a user for viewing and downloading.	NtechLab own deployment
findface-video-streamer-cpu	9000	After receiving a `findface-security-ui` request, this service uses Websocket to extract requested video chunks from `findface-video-storage` and `findface-video-worker` (only the last chunk if it’s not yet recorded to the storage). Then it merges the video chunks into a one-piece video and delivers it to a user for viewing and downloading.	NtechLab own deployment
MongoDB	27017	Third-party software that implements the Video Recorder database. The database stores meta-information of the video chunks, including their location. The video chunks themselves are stored in the `findface-upload` component.	MongoDB

Single- and Multi-Host Deployment 

You can deploy FindFace Multi on a single host or in a multi-host environment. If you opt for the latter, we offer you one of the following deployment schemes:

Deploy FindFace Multi standalone and distribute additional findface-video-worker components across multiple hosts.

See Additional findface-video-worker Deployment on Remote Hosts.
Distribute the FindFace Multi components across multiple hosts. If necessary, set up load balancing.

See Guide to Typical Multi-Host Deployment.

CPU- and GPU-acceleration 

The findface-extraction-api and findface-video-worker services can be either CPU- or GPU-based. During installation from the developer-friendly installer, you will have an opportunity to choose the acceleration type you need.

If you opt to install FindFace Multi from the repository package, deploy the findface-extraction-api and findface-video-worker-cpu packages on a CPU-based server, and the findface-extraction-api-gpu and/or findface-video-worker-gpu packages on a GPU-based server.

Important

Refer to Requirements when choosing hardware configuration.

Important

If the resolution of a camera(s) in use is more than 1280x720px, it is strongly recommended to use the GPU-accelerated package findface-video-worker-gpu.

Note

The liveness detector is much slower on CPU than on GPU.