Articles in this section

Building Linux-based NVRs

Avatar
Nx Support
  • Updated
Follow

Overview

This article describes common steps for a partner who wants to make an NVR-like hardware product – an embedded computer (called here an "NVR") with a pre-installed Server application. Typically, such an NVR is a Linux-based computer with an ARM CPU.

The basic steps to make such a product include the following:

  • Choose hardware
    • Platform
    • Storage
  • Choose Linux flavor
  • Install Server application
  • Implement extra features
  • Establish a support policy

These steps are described below in detail.

Choose hardware

To make a product successful it should be cost-effective and provide the required performance – support the desired number of cameras with the desired bitrate/resolution. Hardware used should have at least 1GB of RAM and an ARM Cortex A7 chipset or higher.

It is recommended to first study the performance of the supported ARM platforms (see ARM Support Policy for the list of such platforms), and then choose a platform closest to your requirements.

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;
  • a reference for designing a custom computer with the 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, such as a web server providing a web interface to the user, video analytics software (e.g. a VMS plugin and/or its backend), or the like, make sure to add sufficient RAM and CPU processing power to cover that. 

Video transcoding is not supported on ARM devices due to 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 can be considered.

The storage performance of the platform should be good enough for the planned load. For example, it is known that solutions such as SATA-over-USB may lead to poor HDD performance, which is insufficient for recording with the required number of cameras.

The network performance of the platform should be good enough for the planned load. For example, it is known that such solutions as software-based Ethernet implementation takes a lot of CPU resources and thus may lead to frame drops while recording cameras or streaming to Clients, or other issues. Additionally, hardware models that implement ethernet via USB hub may have less than the advertised network bandwidth.

The platform should be equipped with a 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 is planned to be the network, it is recommended 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:

  • VMS installation – binaries and dynamic libraries (.so files)
    • Located at /opt/<vendor>/mediaserver/
    • Required space: can be calculated by measuring the total size of the respective files in the distribution with some added margin; the higher the margin – the fewer 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 that are not symlinks can be moved).
  • 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.
  • 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.
  • 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.
  • 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's 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%.
  • 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.
  • 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 things listed above can be assigned to be stored in a different location in the Server configuration file: /opt/<vendor>/mediaserver/etc/mediaserver.conf

Since the typical SD card storage is not reliable and known to fail during intensive read-write operations, we recommend 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.

For instance, for the Raspberry Pi 3 B+:

    • Use USB-SATA adapter and external hard drive for the archive. 
    • Install OS (Raspbian) to an external hard drive. See the article 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 hard disk:
      • With hard disk - make a pre-configured image with 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 pretty complex and time-consuming task.

Choose 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, it is recommended to choose a Linux variant which is the native choice for the platform the NVR is based on. For example, when developing an NVR similar in hardware to Raspberry Pi (or even using the exact Raspberry Pi mainboard), it is recommended to choose Raspbian.

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

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

Install Server application

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

  1. For Debian-based OS: install the official .deb package from the VMS distribution using dpkg.
  2. For Busybox-based OS: extract the required files from the VMS .deb package to the desired directory, and manually take care of the following aspects:
    • How 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 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 that 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 that 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

It is necessary to find or design a case that will fit all the hardware mentioned above.

Conduct Extensive Load/Stress Test

To ensure everything works together, it is necessary to plan an intensive stress test 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, and they will definitely require some kind of technical support. The support team of the VMS vendor cannot render such services to the end-users, thus, a policy for providing such support should be developed, like an online support desk, a community forum, or the like.

When the support team of the NVR vendor is sure that the particular issue is not related to the specifics of the NVR itself, but rather is a problem in the VMS, it may request support from the VMS vendor according to the above-mentioned ARM Support Policy, and then use the outcome of this support case to satisfy the support request from an end-user.

Related articles

Comments

0 comments

Article is closed for comments.