The business of security and surveillance systems has received a significant boost over the past few years due to the appearance and widespread use of protocols and devices; IP-based camera systems have overcome their analog predecessors by adding flexibility, accessibility and improved functionality.
During the early stages, companies engaged in IP cameras development and created their own standards/protocols which forced the end consumer to choose all of the equipment (from front-end cameras to back-end storage devices) from the same manufacturer.
In 2008, Sony, Bosch and Axis established the Open-Network Video Interface Forum (ONVIF) organization that brought to light a solution in the form of a standard to overcome the IP surveillance systems vendors’ interoperability issues. ONVIF has standardized the digital interface of IP surveillance products, unified compression and transmission of video and audio streaming, IP device discovery, pan/tilt/zoom control, alarm inputs/outputs, configuration and control procedures and motion detection among others.
This blog is intended to provide an overview of key aspects of the standard itself as well as explore RidgeRun’s ONVIF Device Server. The ONVIF server offers the user the opportunity to extend the functionality of a video capture Linux-based device to make it capable of receiving and processing ONVIF requests.
ONVIF standard components
ONVIF standard addresses the following topics to assure the interoperability between devices, these are later grouped into profiles:
Device Management: Provides a standardized way to discover, configure, and manage devices on the network.
Media Configuration: Defines the protocols for streaming video and audio, ensuring that devices can transmit and receive media data seamlessly.
Event Handling: Standardizes the way devices handle and communicate events, such as motion detection or tampering alerts.
PTZ Control: Specifies the control mechanisms for pan-tilt-zoom cameras, ensuring consistent operation across different devices.
Video Analytics: It is divided into image analysis and application-specific implementation. The application performs a comparison of the scene based on the objects present and responds to certain rules (virtual lines describing prohibited zones, protected areas, among others).
Security: Ensures secure communication between devices, protecting against unauthorized access and data breaches.
Evolution of ONVIF
The evolution of ONVIF is directly related to the growing needs of the security surveillance industry. The several milestones can be linked to the introduction of the several profiles as part of the ONVIF standard.
Though ONVIF is meant to create a standardized way for devices to interact, not all devices use the same protocols or implement the same functionality, this is the reasoning behind the introduction of the several different profiles which are groups of standardized sets of functionalities and features for various devices and clients to comply with.
Each profile has 3 sets of features: Mandatory (M), Conditional (C) and Optional (O). ONVIF compliant devices and clients must include the mandatory calls in order to adhere to a specific profile.
A summary of the evolution and appearance of some of the most significant profiles can be found below:
ONVIF Core Specification 1.0 (2008): The initial release focused on IP video systems, defining the basic communication protocols.
Profile S (2011): This profile enables simple IP-based video streaming and includes devices such as ONVIF IP cameras, video encoders and network video recorders (NVR). Profile S focuses on:
- Remote video streaming
- Remote video management
Profile C (2013): It focuses on access control systems, supporting functionalities like door control, event and alarm management as well as credential management. Profile C is extended by profile A which adds advanced access rules.
Profile G (2014): Aimed at edge storage and retrieval, it is designed to work with video systems that use IP networks to record and stream data. It supports recording, search and playback of stored video on edge devices such as cameras and encoders.
Profile T (2018): It was introduced to address advanced video streaming capabilities. Some of the focus topics include:
- H.264 / H.265 compression
- Imaging management
- Motion detection
- Video analytics
- Bi-directional audio
- Security features robustness
Profile M (2021): Facilitates the transmission of metadata and event information between devices and applications; it includes support for analytics data such as face detection, object tracking and other AI-based features.
The full set of profiles and documentation can be found here.
ONVIF vs RTSP
A common mistake when discussing IP cameras is comparing ONVIF and RTSP cameras, there is no point of comparison as each refers to a different topic.
As explained earlier in this article, ONVIF is a standard which aims to achieve interoperability of devices from different manufactures by defining a set of guidelines on how each device should communicate and what functionality to implement whereas RTSP is a protocol for network video and audio transmission.
Moreover, an ONVIF compliant camera can rule RTSP protocol though it is not mandatory, other protocols can be used, for example HTTP. Likewise, an IP camera can perform network streaming without necessarily being ONVIF compliant.
RidgeRun’s ONVIF server solution
ONVIF is a particular application of SOAP (messaging protocol over distributed networked system) web services and relies on WSDL (Web Services Description Language) files to expose the standard specifications.
The RidgeRun’s ONVIF server is a Linux process based on gSOAP which is capable of implementing ONVIF server profiles; currently, it implements some (not all) of the Profile S (basic video streaming) requests. Though our product does not support all of the requests needed to be fully ONVIF compliant, it is a great starting point that supports all of the basic requests needed to perform the basic video stream operation:
Create / modify / delete multimedia profile
Video source and encoder configuration
User authentication
Enable auto-discovery, among others
The full list of supported requests can be found here; the ONVIF server is fully extensible per customer’s request, additional ONVIF profiles and requests can be added to the existing core product.
In a simplified manner, RidgeRun’s ONVIF server receives a request from a client through the network, parses it and forwards a command to the multimedia server via internal sockets.
Figure 1. ONVIF system diagram
Figure 1 shows a basic diagram outlining the main components involved in a communication process between a client requesting to get a video feed from your hardware (likely a camera + embedded board) turned into an ONVIF capable system using RidgeRun’s ONVIF Server.
The interfaces defined in the device management and control part of the ONVIF specification are all provided in the form of Web Services; the ONVIF specification covers the complete XML and WSDL definitions. Each terminal device that supports the ONVIF specification must provide a web service corresponding to the function. The data exchange between the server and the client uses the SOAP protocol whereas other parts of the ONVIF, such as audio and video streams, are carried out through RTP/RTSP over HTTP.
The core logic of the product is meant to abstract the complexity of implementing some of the underlying layers required to establish the communication and provide the customer with a simple set of callback functions to solely describe the multimedia functionality (stream creation and manipulation); ultimately, the customer just needs to include the library as part of their application and provide the implementation of these callbacks.
Figure 2. Implementation of RidgeRun’s ONVIF Server
In Figure 2, a list of the customizable blocks of the ONVIF Server are shown, the full description of each can be found here. The server itself comes with a reference implementation for each one of 3 leftmost blocks, leaving just the iMediaClient (responsible for creating and deleting the RTSP multimedia streams) as the one that necessarily needs to draw your attention; the product itself comes with an implementation based on GStreamer plugins and RidgeRun’s GstRTSPSink and Gstreamer Daemon but the customer is free to use the framework (FFMpeg for example) of their choice for the implementation of the media server component.
For NVIDIA Jetson-based systems, RidgeRun offers a complementary product, the ONVIF Device Reference Design which is based on ONVIF Server and provides a simple configuration interface for the server via a web page. A high-level diagram of the solution can be found here.
Do not hesitate to contact us in case you are curious about how ONVIF Server or any of the RidgeRun's products and services can help your team speed up your product’s time to market.
Comments