Articles in this section

Building Linux-based NVRs

Avatar
Nx Support
  • Updated
Follow

Overview

This article describes common steps for creating an NVR-like hardware product — an embedded computer (an "NVR") with a pre-installed Server application. This type of NVR is typically a Linux-based computer with an ARM CPU.

The basic steps to create an NVR are as follows:

  1. Choose your hardware
    1. Platform
    2. Storage
  2. Choose a Linux flavor
  3. Install the Server application
  4. Implement extra features
  5. Establish a support policy

These steps are described below in detail.

Choose your hardware

For a product to be successful, it should be cost-effective and perform as required; e.g. support the desired number of cameras with the desired bitrate/resolution. The hardware chosen should have at least 1GB of RAM and an ARM Cortex A7 chipset or higher.

For a better understanding of the supported ARM platforms and their performance, please refer to ARM Support Policy. Select the platform that best suits your needs.

Platform

The chosen supported ARM platform can be used as one of the following:

  • a ready-to-buy computer (e.g. a standard Raspberry Pi mainboard), possibly with a custom case and power supply unit; or
  • a reference for designing a custom computer with a mainboard that may host additional hardware components like peripheral interfaces or hard drive controllers.

If the NVR is expected to have additional software onboard besides the Server application, make sure the NVR has enough RAM and CPU processing power. This additional software can be a web server providing a web interface to the user, video analytics software (e.g. a VMS plugin and/or its backend), etc.

Video transcoding is not supported on ARM devices due to their limited computing power. Additionally, some dependencies such as OpenSSL may have compatibility issues. If the initial analysis shows that a typical ARM-based platform will not provide the required performance, an x64 platform may be considered.

The storage performance of the platform should meet the requirements of the planned load. For example, solutions such as SATA-over-USB may lead to poor HDD performance, which may be insufficient for recording with the desired number of cameras.

The network performance of the platform should also meet the requirements of the planned load. For example, solutions such as software-based Ethernet implementation are CPU-intensive and may lead to frame drops while recording with cameras or streaming to Clients. Additionally, hardware models that implement ethernet via a USB hub may have less network bandwidth than advertised.

The platform should be equipped with Real-Time Clock (RTC) hardware, and/or time synchronization via the network (e.g. using the NTP protocol) should be enabled. For the VMS to function correctly, the OS date and time must be correct. If there is no hardware RTC, and the only date/time source will be the network, it is possible that the device will refuse to start at all in case it cannot synchronize the date/time.

Storage

Make sure there is enough space on the filesystem for the VMS to function properly. The Server uses the following storage locations:

  1. VMS installation — binaries and dynamic libraries (.so files)
    • Located at /opt/<vendor>/mediaserver/
    • Required space: can be calculated measuring the total size of the respective files in the distribution with some added margin; the higher the margin – the less chances for issues with updating to future versions. Generally, a 30% margin is recommended.
    • If there is not enough storage at /opt, .so files can be moved via symlinks to another location, including FAT32 storage (but in this case only files which are not symlinks can be moved).
  2. Server database files — stores information about cameras and other Servers, event logs, etc.
    • Typically located at /opt/<vendor>/mediaserver/var/; can be changed in the Server configuration file.
    • Requires ext4 filesystem
    • Required space: depends on the number of cameras and Servers in the VMS System, but generally at least 500 MB is recommended.
  3. Server Analytics database — stores Video Analytics metadata generated by Analytics Plugins
    • Typically located at /opt/<vendor>/mediaserver/var/data; can be changed in the Server configuration file.
    • Required space: depends on whether Analytics Plugins are in use on this Server, and how much metadata will the Plugins send. Generally, 20% of the Video Archive Storage size is recommended if Analytics Plugins are used on this Server.
  4. Server logs
    • Located at /opt/<vendor>/mediaserver/var/log/
    • Can be relocated via mediaserver.conf.
    • Logs are automatically overwritten in a loop.
    • Required space: at least 260 MB is recommended.
    • NOTE: We noticed that on specific ARM devices (e.g., Raspberry Pi 3), the internal flash memory (Micro SD in that case) was not good enough to accept logs. The system would freeze for up to 4 seconds. We recommended redirecting logs to the same location as the video archive for such devices.
  5. Video archive — stores the recorded video from cameras
    • Typically located at /opt/<vendor>/mediaserver; can be changed in the Server configuration file.
    • The system partition will likely be restricted from recording by default unless there is at least 10 GB of free space. 
    • Internal flash memory (eMMC) or SD Card
    • Estimate how many write cycles the memory can accept. The video archive is automatically overwriting itself in a loop, thus, the duration of a single write cycle can be calculated by dividing the free space by the combined bitrate of all cameras being recorded on the Server.
    • Make sure that the memory throughput is enough for the combined bitrate of all cameras being recorded on the Server, with a safety margin of 30%.
    • Internal HDD or SSD
    • Make sure that the disk throughput is enough for the combined bitrate of all cameras being recorded on the Server, with a safety margin of 30%.
    • External NAS
    • Make sure that the network adapter actual bandwidth is enough for the combined bitrate of all cameras being recorded on the Server multiplied by 2 (because the cameras presumably send their streams to the Server using the same network adapter), with a safety margin of 30%.
  6. Server application update files
    • To be able to update, the Server application needs to download its newer version and unpack it.
    • Located at /tmp/
    • Required space: the total size of the packed Server distribution file multiplied by 2.6; this includes the margin. More space can be recommended to minimize chances for issues with updating to future versions.
  7. OS temporary files
    • Typically located at /tmp/
    • Required space: at least 100 MB is recommended, not including the required space for the Server application update files (see above).

Most of the items listed above can be reassigned to be stored in a different location, by modifying the Server configuration file: /opt/<vendor>/mediaserver/etc/mediaserver.conf

SD card storage is typically not reliable and is known to fail during intensive read-write operations. A better option is to install the OS and store the video archive on a hard drive(s). If an SSD/hard drive or SD card is considered for storing the video archive, assess its capability for multiple rewrite operations using the typical bitrate of a desired supported camera multiplied by the desired number of supported cameras.

As an example, for the Raspberry Pi 3 B+:

    • Use a USB-SATA adapter and an external hard drive for the archive. 
    • Install the OS (Raspbian) to an external hard drive. Refer to How to boot your Raspberry Pi from a USB mass storage device for details. This process should be automated depending on how ARM devices are going to be distributed: with or without a hard disk:
      • With a hard disk — make a pre-configured image with the VMS installed and clone it to hard drives.
      • Without a hard disk — you will have to create a set of scripts that formats HDD, copies the OS and does all necessary tweaks. This is a complex and time-consuming task.

Choose a Linux Flavor

There are usually several options for Linux OS on a given NVR:

  • "Busybox" — just Linux kernel and the basic set of command-line tools; used on relatively low-performance NVRs such as "edge" cameras (cameras with the VMS Server running on them).
  • Standard Debian, or one of its flavors like Ubuntu.
  • Modified version of Debian or another Linux distribution, usually modified by the device vendor (e.g., Raspbian for Raspberry Pi).

Generally speaking, choosing the Linux variant that is native to the platform the NVR is based on is recommended. For example, when developing an NVR similar in hardware to Raspberry Pi (or even using the exact Raspberry Pi mainboard), choosing Raspbian is recommended.

If several Linux distributions with different sets of packages are available for the device, select the least resource-intensive one. For example, if there is no plan to show a GUI on the NVR, there is no need for an X Window System. 

Make sure the Linux version and its set of packages satisfies the requirements of the VMS. For ARM-based devices, consult the OS details specified in the ARM Support Policy.

Install the Server application

After the NVR is loaded with a Linux OS, the Server application should be installed on the NVR. There are two options:

  1. For a Debian-based OS, install the official .deb package from the VMS distribution using dpkg.
  2. For a Busybox-based OS, extract the required files from the VMS .deb package to the desired directory, and manually address the following aspects:
    • How will the Server will be started upon boot and if system.d support from the distribution is not suitable.
    • Where will the Server take .so libraries that are missing in the installed Linux?
    • Will the standard VMS automatic update system be enabled?

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

Implement extra features

Typically, an NVR is not just a standard Linux computer with the Server application installed — it often provides additional features to the user:

  • Hardware buttons, LEDs or even embedded displays.
  • A web interface which allows you to customize the NVR beyond just setting up the Server application via its own web interface, such as
    • networking options: IP address, subnet, etc.;
    • system time and time zone;
  • Video output (e.g., HDMI) which shows a GUI or at least a welcome screen with basic configuration values like the NVR's IP address;
  • Additional software which runs in parallel to the VMS, such as a configuration daemon or a video analytics backend.
    • If the additional software has a password-based authentication for the end user, consider implementing password synchronization, so that the VMS Server password is always the same as the one for the additional software. If ssh is offered to the user to access the NVR, consider synchronizing its password as well.
  • Additional tweaks, like minimizing video (GPU) memory. For instance, for the Raspberry Pi 3 B+ set the GPU memory to 16 MB. See Raspberry Pi documentation for details.

To implement such features, it may be required to write or modify scripts that control the Server application, or write additional programs in C/C++.

Time Synchronization

Make sure the NVR has a built-in CMOS battery to prevent its clock from resetting in the event of power loss. For instance, Raspberry Pi 3 B+ does not have a CMOS battery onboard. If the device is rebooted, the time will reset and it will result in incorrect archive writing. To avoid this, there are some options:

  • Make sure it is connected to the internet to synchronize time. 
  • If it is a closed network, you will have to set up an NTP server. 
  • Add a Real-Time Clock (RTC) module to the board and pre-configure it. See Adding a Real Time Clock to your Raspberry Pi.

Finding/Building an Enclosure for Your NVR

The case for the NVR should be able to fit all the necessary hardware mentioned above.

Conduct Extensive Load/Stress Test

An intensive stress test is necessary to ensure there is no overheating or component malfunction. The test should be able to load all the system components like CPU, Memory, Hard disk(s), Network, and Wi-Fi (if necessary), etc.

Establish Support Policy

The NVR is going to be supplied to its end users, who will require some kind of technical support. The support team of the VMS vendor cannot render such services to the end users; therefore, a policy for providing such support should be developed, like an online support desk, a community forum, etc.

If a particular issue is not related to the NVR itself (as determined by the NVR support team) but to the VMS instead, then the VMS support team should be contacted. Please refer to ARM Support Policy for more information.

Questions

If you have any questions related to this topic or you want to share your experience with other community members or our team, please visit and engage in our support community or reach out to your local reseller. 

Related articles

Comments

0 comments

Article is closed for comments.