This section covers tools and techniques for debugging plugins during development. It assumes the plugin builds and runs. Start here when you need to diagnose loading failures, instrument your code, or test against video streams.

Before starting: obtain the Server Plugin SDK archive from the developer portal, read the included readme.md, and verify you can build and run at least one of the provided samples. For domain-specific SDK content (interfaces, analytics capabilities), see the Doxygen documentation at docs/html/index.html.

For SDK layout and build configuration, see Server Plugin SDK Structure and Building Plugins.

Server Plugin SDK Structure

This article covers the structure of the Server Plugin SDK package for developers building or extending plugins.

SDK Structure

Currently, SDK supports developing of the following plugin types:

• Video Analytics Plugin,
• Video Source Plugin known as Camera Plugin,
• Storage Plugin,
• Cloud Storage Plugin,
• Combined Plugin.

The SDK code is based on the common concept of reference-countable objects (like COM technology), and, as a result, share a number of identical C++ files. The SDK package contains only text files, html pages, and C++ source code.

The source code has the following structure:

• src/nx/sdk/: The SDK Core (defining the API between the Media Server and a plugin), and its helper code. The subfolders nx/ and sdk/ are needed to reflect the C++ namespaces (this is a part of the coding style)
  • i_*.h: Headers that define SDK Core interfaces. They support the plugin infrastructure and are not domain-specific (e.g. they don’t mention working with video).
  • *.h (w/o i_ as prefix): Headers for basic SDK Core features, like the concept of an interface as a header-only class with pure virtual functions and inherited objects managed by reference counting, like in COM technology, a smart pointer which manages the reference counting, and some utility classes.
  • helpers/: Classes and functions which can be helpful when writing a plugin but are not mandatory. Most of them provide default implementations for certain interfaces but are extensible, inherit from a helper class, and override the functions that don’t suit your needs.
  • analytics/: The domain-specific part of the SDK intended for creating Video Analytics Plugins, which typically analyze video and supply metadata to Media Server. Contains interfaces, and the optional-to-use helper code, default extensible implementations of the interfaces.
  • cloud_storage/: The domain-specific part of the SDK intended for creating Cloud Storage Plugins, which typically receive video stream data from the Media Server and write to a Cloud storage. Contains interfaces, and the optional-to-use helper code, default extensible implementations of the interfaces.
• src/plugins/: The old-style Plugin interfaces not yet migrated to the newest SDK Core (see above). The folder contains common interfaces used for creating Camera and Storage Plugins (see below).
• src/camera/: The domain-specific part of the SDK intended for creating Video Source Plugins known as Camera Plugins. It’s based on the old-style Plugin interfaces not yet migrated to the newest SDK Core (see above).
• src/storage/: The domain-specific part of the SDK intended for creating Storage Plugins. It’s based on the old-style Plugin interfaces not yet migrated to the newest SDK Core (see above).
• nx_kit/: A standalone, self-contained helper library (see paragraph below). Using this library in your plugin is not mandatory, but the included plugin samples extensively rely on it, as does this guide.
• samples/: plugin samples; each subfolder represents a plugin.
• unit_tests/: unit tests covering the code in the src folder: the SDK core and certain helpers.
• docs/: HTML specification for all the C++ source code in the SDK package, including the plugin samples; generated by Doxygen.
• build_samples*: sample-building scripts for different platforms.
• readme.md: the main readme document for the SDK

The nx_kit helper library

The support for some essential technologies is unfortunately still missing from the C++ standard library, including: JSON parsing/generation; reading .ini files; assertions that work in both Debug and Release builds; and convenient logging.

The SDK includes a small, pure C++ library called nx_kit which covers these topics. For details, see nx_kit/readme.md. This library is used only in helper code included with the SDK, but not in the core SDK components, and is optional. However, nx_kit is widely used in the provided samples, and many recommendations in this guide are based on it.

Since the SDK is an open-source package, the SDK Core (which offers reference-countable objects) and its helper code are available for introducing plugins into any other C++ project.

Building Plugins

The Media Server Plugin SDK supports multiple build methods and target platforms. Start with the included build scripts to verify the toolchain, then switch to your preferred IDE or CMake workflow.

Build Methods

The officially supported “entry point” method of building plugins is running a sample building script included with the SDK.

• for Linux or Cygwin: build_samples.sh,
• for Windows: build_samples.bat

Consult the readme and try it before using a different method (e.g., using an IDE). Once you can run the sample building script successfully, switch to a more familiar method; the popular methods are:

• Using cmake from the command-line, in combination with a text editor like Notepad++, vim, emacs, or Visual Studio Code.
• Using an IDE, like Qt Creator, Visual Studio, or CLion.

To ease your transition to an IDE or your own method of building, explore the console output of the script, it shows each command essential to the build process. When in doubt, use the source code of the script to learn more. Then, try to build the sample of your choice, issuing the necessary commands manually, it will help to understand the details.

Cross-Platform Considerations

The SDK and its samples are cross-platform, can be built on Windows or Linux, including cross-compiling for ARM-based devices. Decide whether the plugin should be cross-platform, any platform works for development, but testing must cover each target platform.

Cross-platform plugins reach a wider user base, but at a cost; all the source code you write and the libraries you use must be cross-platform as well, so either have a specific version for each platform or be platform-agnostic.

If you are new to C++, use the C++ standard library for cross-platform plugins wherever possible. The SDK and its included samples use the language features up to C++17, and require no additional libraries, but the code you write can use any higher language standard.

C++20 offer many standard library features; they include file system (walking through directories and files on disk), multi-threading support, and regular expressions. Any popular cross-platform C++ library (Boost, Qt) can also be used.