This guide describes how to create an embedded network video recorder (NVR) hardware product or an Edge camera device with a pre-installed Video Management System (VMS) server application. Typically, these systems use an embedded Linux computer with an ARM CPU.

To build a custom VMS-integrated device, complete the following steps:

1. Select the hardware platform

2. Configure storage system requirements

3. Select a Linux distribution

4. Install the VMS server application

5. Implement custom features

6. Perform stress testing

7. Establish a support policy

Select the hardware platform

To ensure your device supports your targeted camera count, bitrate, and resolution efficiently, select hardware that meets or exceeds the following minimum requirements:

• RAM: 1 GB minimum. Add more RAM if you plan to run additional software like custom web interfaces or video analytics plugins.

• CPU: ARM Cortex A7 chipset or higher.

Platform implementation types

You can deploy your hardware platform in one of two ways:

• Off-the-shelf single-board computers (SBCs): Use a ready-made board (such as a Raspberry Pi) housed in a custom enclosure with an external power supply.

• Custom hardware designs: Use a supported ARM reference design to build a proprietary mainboard. This allows you to integrate dedicated peripheral interfaces or hard drive controllers directly.

Network and time synchronization requirements

• Network throughput: Avoid software-based Ethernet implementations, which consume high CPU cycles and cause dropped frames during multi-camera recording. Ensure the physical hardware does not route Ethernet through a shared USB hub, as this limits advertised network bandwidth.

• Time synchronization: The VMS requires accurate system time to index video correctly. Equip your hardware with a dedicated Real-Time Clock (RTC) chip and battery backup. If the device relies entirely on Network Time Protocol (NTP) over a network, configure the OS to block the VMS application from starting until time synchronization completes.

Configure storage system requirements

Do not use standard SD cards or internal eMMC flash memory to store video archives. Continuous read/write cycles cause high failure rates on flash-based media. Install the operating system and video archive on high-endurance hard drives (HDDs) or solid-state drives (SSDs).

Ensure your file systems provide enough capacity and performance for the following VMS components:

VMS Binaries

• Default path: /opt/<vendor>/mediaserver/

• Requirements: Total size of the distribution pack plus a 30% safety margin to accommodate future upgrades.

Server Database

• Default path: /opt/<vendor>/mediaserver/var/

• Requirements: 500 MB minimum. Requires an ext4 filesystem. This database stores critical camera records, system logs, and Server mesh data.

Analytics Metadata

• Default path: /opt/<vendor>/mediaserver/var/data

• Requirements: Allocates a minimum of 20% of the active video archive size if your setup uses active video analytics plugins.

Server Logs

• Default path: /opt/<vendor>/mediaserver/var/log/

• Requirements: 260 MB minimum.

• ARM optimization: For low-spec ARM boards (such as the Raspberry Pi 3), redirect these logs to the video archive drive to prevent system-wide write freezes.

Video Archive

• Default path: /opt/<vendor>/mediaserver

• Requirements: Capacity varies by retention needs. Storage buses must maintain a 30% bandwidth safety margin above the combined bitrate of all concurrent camera streams.

Update Cache

• Default path: /tmp/

• Requirements: 2.6x the storage size of the packed server distribution file to allow safe extraction during remote updates.

OS Temporary Files

• Default path: /tmp/

• Requirements: 100 MB minimum. Maintain this space independently of your update cache requirements.

Automated disk imaging example (Raspberry Pi 3 B+)

When distributing custom hardware, automate your storage deployment using one of these two deployment methods:

• Devices with hard disks: Install the OS and VMS on a master drive, configure your settings, and clone the image directly to production hard drives.

• Devices without hard disks: Create installation scripts that automatically partition and format target HDDs (ext4), copy the base OS, and apply required configuration tweaks.

Select a Linux distribution

Choose a lightweight Linux distribution that natively supports your hardware platform. If your device does not output a local graphical UI, use a minimal headless distribution to save system resources.

Common choices include:

• Debian / Ubuntu flavors: Highly recommended for stability. Use customized, vendor-supported versions like Raspberry Pi OS when applicable.

• BusyBox: Use this minimal footprint environment for low-performance environments, such as Edge cameras running VMS software directly on the camera hardware.

Verify that your selected kernel and package ecosystem align with the requirements listed in the ARM Support Policy.

Install the VMS server application

Depending on your chosen Linux distribution, choose one of the following installation methods:

Method 1: Debian-based distributions

Install the official .deb package using the package manager:

sudo dpkg -i <package_name>.deb

For detailed instructions, see the ARM SBC Installation Guide.

Method 2: BusyBox-based distributions

Extract the required VMS binaries and shared libraries (.so files) from the official .deb package manually. If you use a BusyBox environment, you must manually manage the following processes:

• Configure custom initialization scripts if systemd is unavailable on the platform.

• Map missing dependencies and dynamic .so libraries to accessible file paths.

• Develop a custom mechanism if you want to support automatic software updates.

For less typical OS setups, some combination of options 1 and 2 may be required.

Implement custom features

Custom NVR products usually require additional software integration to manage hardware features. Common enhancements include:

• Hardware controls: Developing scripts to drive physical LEDs, status displays, or reset buttons.

• Custom web interfaces: Providing users a web portal to configure device network settings (IP addresses, subnets) and system time zones.

• Local video output: Configuring the HDMI output to display a custom welcome graphic or a troubleshooting dashboard showing the device's IP address.

• System optimization: Adjusting hardware memory maps to maximize system efficiency. For example, on a Raspberry Pi 3 B+, limit the GPU memory allocation to 16 MB within config.txt to free up system RAM for the VMS. Official documentation HERE. 

• Credential synchronization: If you run a custom configuration daemon alongside the VMS, build a synchronization service. This ensures user password changes propagate uniformly across the web interface, SSH access, and the VMS server software.

Perform stress testing

Before deploying your device to production, perform continuous load and stress testing. Your test suite must simultaneously maximize utilization across the CPU, RAM, network interfaces, and storage buses. Verify that the device maintains stable operating temperatures and does not drop video frames under peak load conditions.

Establish a support policy

As the hardware manufacturer, you must provide tier-1 and tier-2 technical support for your end users. The VMS software vendor does not support custom hardware deployments directly.

To qualify for escalation to the VMS vendor, the reported issue must be fully reproducible on supported hardware running a supported OS. All custom solutions are strictly excluded from VMS vendor support, unless the issue is explicitly and confidently isolated to the VMS software itself.

You must establish an independent support infrastructure. If your support engineering team isolates a technical issue, verifies it on supported x64/ARM configurations, and determines it stems directly from the VMS core rather than your custom hardware, you can escalate the issue by opening a ticket with the vendor.