1. System Overview

MirAI-V2 is an on-premise AI Video Management System (VMS) provided by MarkAny Co., Ltd. It ingests video from IP cameras (ONVIF / RTSP), uses an AI inference engine running on an NVIDIA GPU to detect events such as object detection, fire/smoke, fall-down, and intrusion in real time, and provides recording, re-streaming, notification, and monitoring through a dedicated client. All processing — including AI inference — is completed within the on-premise server; video data is never sent to any external cloud.

The system is organized into three principal layers (subsystems):

• Camera layer: A fleet of IP cameras compliant with standard protocols (ONVIF / RTSP). The server connects to each camera and pulls the video via RTSP.
• Server layer (MirAI Server): The core of the system. It handles video ingestion (GStreamer), the AI inference engine (GPU / TensorRT), the REST / WebSocket / TCP APIs, the PostgreSQL database, the RTSP re-streaming server, and the recording storage. It is implemented in Rust (Axum), with the AI inference engine running as an in-process DLL.
• Client layer (MirAI Client): A dedicated monitoring application implemented in Qt / C++. It provides live grid viewing, AI pipeline editing, and review of notifications and incident logs. It connects to the server over encrypted channels (HTTPS / WSS / TCP).

The major subsystems are as follows.

2. Architecture Diagram

The block diagram below shows the system components and the data/control flow between cameras, server, and client. The protocol and port are labeled on each arrow.

3. Components

The role and technology of each component are listed below.

4. Network Configuration

MirAI-V2 uses the following ports and protocols for client/server communication and for communication with cameras. When the client and server are on different machines, allow inbound traffic for the relevant ports in the server-side firewall.

4.1 Service Ports (Client ↔ Server)

4.2 Server ↔ Cameras / Database

5. Physical Deployment

MirAI-V2 supports both a single-server configuration for smaller deployments and a multi-GPU configuration for high-density operation. Adding GPUs scales camera capacity horizontally.

5.1 Single-Server Configuration (Standard)

In the standard configuration, a single GPU-equipped Windows server runs the launcher (Windows service), the MirAI Server (API, AI engine, ingestion), PostgreSQL, and the recording storage all on one machine. Clients connect from the same machine or from separate machines over LAN / VPN.

5.2 Multi-GPU Configuration (High-Density Operation)

For high-density operation with concurrent AI inference across many cameras, multi-GPU configurations (2 CPU / 4–8 GPU) are supported. One inference engine instance is assigned per GPU, and cameras are distributed across GPUs (via a frame router) to balance the load. Guidance on camera capacity by GPU memory (VRAM) is shown below.

6. Data Flow

The end-to-end flow — from camera ingestion to display and notification on the client — is shown in numbered steps.

1. Video ingestion (camera → server): The server connects to each camera via RTSP (port 554) and pulls video using GStreamer. A tee splits the stream into a "recording / re-stream branch (passthrough)" and an "AI inference branch (decode)".
2. Decode and frame extraction (ingest → AI): On the AI branch, NVDEC (GPU hardware decoder) decodes the video, the frame rate is throttled for analysis (default cap of 7–10 fps), and frames are extracted.
3. AI inference (AI engine): Extracted frames are batch-processed on the GPU (TensorRT / ONNX Runtime), running detection → classification → tracking. In multi-GPU configurations, a frame router distributes cameras across GPUs.
4. Event evaluation (rules): Detection results are evaluated against the defined event rules and false-positive thresholds (e.g., fire 0.45 / smoke 0.40 / fall-down 0.80); an incident is generated when conditions are met.
5. Recording and persistence (passthrough branch → storage / DB): The encoded video on the passthrough branch is stored as recording files (60-second segments), and incident information (thumbnail, video path, type, confidence, timestamp) is written to PostgreSQL.
6. Notification and delivery (server → client): After applying notification rules (rate limiting, quiet hours, etc.), incidents are dispatched to the configured channels (Email / Webhook / SNMP / HTTP) and broadcast to connected clients over WebSocket (7575).
7. Client display (client): The client shows incidents received over WebSocket in the notification panel, fetches thumbnails and video clips over HTTP (7878) / TCP (7979), and displays live video via RTSP re-streaming (8554 / 8555).

7. Notes and Assumptions

• This is an on-premise system (installed on the customer's premises). AI inference is completed within the server; video data is not sent to any external cloud.
• An NVIDIA GPU is required for AI inference. AI features will not operate on non-NVIDIA GPUs or on systems without a GPU.
• The confirmed values in this document (ports, protocols, technologies, etc.) are based on the standard configuration of MirAI-V2 v2.0.3.
• Capacity, frame-rate, and similar figures shown in the diagram and text are guidance and are finalized during sizing based on the customer's operating conditions (camera count, resolution, analyzed FPS, retention period, etc.). Please also refer to the separate "System Requirements" document.
• The contents of this document are subject to change without notice due to product improvements and other factors.