Next-Gen Engine Architecture
A BriefCam Next-Generation deployment includes, at minimum, a Linux processing server and a Windows BriefCam main server (or system of servers).
The main component that supports the real-time Next-Gen engine is the OX6 Engine Service. The OX6 engine server, running Linux, hosts the GPUs, performs the actual processing, and replaces the OX5 Alert Processing Server. When the deployment is configured to run with the OX6 engine and the OX6 Engine Service is activated, these OX6 Engine Services will start taking on real-time processing tasks, similar to the OX5 Alert Processing Server functionality.
The OX6 Engine Service will be orchestrated using the Host_Controller Windows service, similar to the VSService Windows service.
The diagram below depicts a basic deployment using the Next-Gen engine.
The OX6 Engine Service runs on Linux inside a container and is managed by the Host_Controller service, which manages a cluster of servers and a pool of GPUs.
The OX6 Visual Assets Service stores video clips and masks from the Next-Gen engine (using the HTTP protocol).
The Common Platform API service provides the OX6 engine and Linux services with the essential data needed for execution.
RabbitMQ serves as middleware and passes the messages/notifications to and from the BriefCam Task Management service to the alert processing servers.
NGINX functions in this architecture as a load balancer.
Let’s see how this works when a user creates a rule in BriefCam:
The BriefCam Task Management service sends/distributes processing tasks to the alert processing servers using RabbitMQ.
Each alert processing server then needs to get the live stream. The VMS Adapter service is responsible for translating the Windows SDK method of retrieving the RTSP URL to the Linux server. It is the bridge between existing integrations plugins (see BriefCam’s Supported VMS page for information about integrations with Next-Gen support) and RTSP live streams expected by the Next-Gen engine.
The Next-Gen engine processes the stream using the OX6.Engine Service. This service will take ensure that processing the stream will not exceed that GPU’s processing capacity.
Via NGINX, the OX6.Engine Service sends metadata and visual assets to the OX6.Engine Gateway Service and the OX.Visual Assets Service. Those services distribute the alerts, write the objects, and more.
The Host Controller is a Linux service running on the Linux machine and is responsible for managing the engines. (There is one engine service per GPU on the machine.) It is the service that communicates control information to and from the engines (start, stop, status, logs, and more).