Bosch’s Bob Banerjee and Gerard Otterspeer discuss what’s in store for video standards in the December issue of Security Technology Executive.
From l-r, Bosch Security Systems’ Bob Banerjee and Gerard Otterspeer look at the past, present and future of video standards.
End-users, consultants and specifiers want more choices to assure they are getting the best of breed. Integrators want equipment to work and be plug-and-play. They do not want surprises as they start connecting equipment, which can erode precious margins and their reputation. Manufacturers want to grow.
These possibly over-simplified needs are eternal. They are as true in the past as they will be in the future. They are not new in the world of IP video, as while you could plug an NTSC analog camera into a DVR via coax to see and record video, you were stuck in one fixed position with analog PTZ cameras. Sure, you could view the video, but unless the DVR knew how to control the PTZ camera, you couldn’t move it. The control mechanism, also known as a protocol, was not standardized. Instead, the largest manufacturers each had their own and others started to simply reuse them rather than reinvent them. The bottom line was that if you wanted a PTZ camera and a DVR from two different manufacturers, you had to make sure they could speak the same protocol and then you had to manually set it.
In the world of IP video, there are similar issues with incompatibility. However, there are more severe consequences, because there are a whole host of things that travel between the camera and recorder, including compressed video, audio, camera settings, information about the PTZ’s current position and even information about the scene — such as whether someone is loitering or how fast a car is driving through a parking lot, possibly even its color. This has become possible because the camera is more intelligent and can communicate data.
The video surveillance market has turned its back on proprietary solutions with the creation of at least two bodies, ONVIF and PSIA. The Open Network Video Interface Forum (ONVIF) was founded by Axis, Bosch and Sony back in May 2008, with a clear focus on network video devices. The Physical Security Interoperability Alliance (PSIA) began in the same year with a broader scope that encompassed more areas of security devices. The existence of two competing bodies has driven each to progress faster than is typical and each has had published specifications for some time now.
Technically speaking, both ONVIF and PSIA have created specifications, not standards. To become a true standard like NTSC, a standards body would have to accept it using a rigorous process. But these specifications are the first step towards that ultimate goal.
Compatibility before ONVIF and PSIA
Even before ONVIF and PSIA, there was a work-around to ensure compatibility. The creators of “open” video management software (VMS) that view and record different manufacturers’ cameras have invested huge amounts of effort in integrating and testing each camera using a piece of software glue called a Software Development Kit (SDK) that comes from the manufacturers. SDKs are available for most things, including IP cameras, encoders, DVRs, network video recorders and even video management systems themselves. SDKs allow you to squeeze out every differentiated feature from a device, but also require a huge amount of up-front and maintenance effort.
Now that we have a better understanding about current SDKs, let’s take a closer look at one of the standards candidates, ONVIF, so we can investigate what it means to the marketplace (see PSIA Executive Director Dave Bunzel’s sidebar on his organization, page 26).
ONVIF has created a specification which is simply documents that define how networked entities (let’s keep it simple and assume an IP camera and a VMS), can communicate and understand each other’s capabilities. The classic analogy is ONVIF specifies a common language, say English, so that these entities can speak to each other. They depend on this common language to exchange all kinds of information to reach conclusions such as “Shall we use H.264, MPEG-4 or JPEG — what would you prefer?”, “Do you mind setting your current time to 10:35 a.m.?” or “Would you kindly jump to preset 8?”
ONVIF functionality can be grouped into the following areas:
• Device discovery — so that a VMS can find ONVIF devices across the network and ignore all others;
• Device management — to set up the device, including its IP address, system time and categorize it as fixed or PTZ;
• Imaging / Media configuration — to understand the current video quality settings and then set them, e.g., 30 frames per second at 4CIF, with a bandwidth limit of 2Mbps;
• Real-time streaming — to stream video, audio and metadata from the IP camera to the VMS;
• Event handling — to receive alarms and other events; and
• PTZ control.
The ONVIF specification will eventually lead to the creation of an SDK that anyone can use to leverage the benefits of ONVIF without implementing it from scratch. Different manufacturers will create these SDKs — some will be more programmer-friendly than others — that should all provide the same ONVIF functionality.
An ONVIF SDK is not mandatory because of the use of an open standard called “web services,” where the interface itself is already described in the Web Services Description Language (WSDL) files from ONVIF. Additionally, ONVIF offers software test tools that enable developers to test for ONVIF compliance.
Streaming Compatible Video
People often mistakenly think that ONVIF defines how to stream video and how that video should be compressed. Actually, ONVIF simply re-uses existing industry standards for both. Streaming is done in the ONVIF specification via the well-established Real Time Streaming Protocol (RTSP). All ONVIF has to do is configure the devices to use the right settings, and RTSP does the rest. When the video reaches the destination — in our case, the VMS — it needs to be displayed, or “decoded.” There are numerous software decoders available off the shelf that you can use to view the streaming video, including Apple’s QuickTime and VideoLAN’s VLC player.
Here’s how it works: the VMS requests the status of the streaming settings and connects to the video stream. This is done by requesting the streaming Uniform Resource Identifier (URI) address to send video streams and connect to this URI. The VMS then plays the video via its integrated decoder or an RTSP-compatible decoder like QuickTime. We can use the same streaming address to record the video on a network video recorder or an ONVIF-compliant hybrid recorder.
Because of historical issues with incompatible video formats, referred to as CODECs, people often assume that ONVIF would have to specify a standard for compression. Instead, the ONVIF specification says you can use H.264, MPEG-4 (Part 2) and JPEG. The compression algorithm used in a real deployment will depend on what the camera can deliver and what the VMS can handle, but the wonderful thing is that JPEG is the bare minimum — a camera or VMS cannot declare ONVIF compatibility without supporting at least JPEGs.
An important note about video quality, especially MPEG-4 and H.264: both CODECs enable manufacturers to compress video without losing too much detail while minimizing bandwidth and storage. Manufacturers differentiate from one another by using the tools in different ways, which means that it is common for two IP cameras to present completely different image qualities and need different bitrates in a given scenario. Fortunately, this does not require a manufacturer-specific decoder at the other end, since all decoders can handle these streams. However, just like IP camera manufacturers vary in the quality of the compressed image, software decoders vary in the quality of how they decompress.
It is shocking to many that an IP camera streaming H.264 video can look completely different depending on the software being used to decode the video — even if they are running on the same PC. All H.264 decoders will work, but some look better than others. This is why it is so important for a VMS to use the best possible decoder, and this is a major point of differentiation between VMSs that cannot be articulated in datasheets, PowerPoint slides or advertising. Seeing is believing.
In 2009, several manufacturers released ONVIF-compliant IP cameras, encoders and recorders, as demonstrated recently at a so-called plug-fest, and repeated at ASIS 2009, where nine industry players demonstrated interoperability. Since the ONVIF-compliancy roadmap and schedule for manufacturers and software vendors is a confidential and internal matter, it is impossible to say with any certainty when the leading VMS vendors will officially release ONVIF support. However, I speculate they, along with hardware edge device manufacturers, will announce this in early 2010.
At the time of writing this article, ONVIF has 112 members and as stated by IMS research in July of 2009, ONVIF member companies account for roughly 60 percent of the network video surveillance equipment market. The membership includes Axis, Bosch, Sony, Panasonic, Cisco, Samsung, Genetec and Milestone plus many other significant hardware and software manufacturers, distributors, integrators and others from around the world.
The progress of these organizations’ standardization efforts is unstoppable, not only because the members wish it to be successful, but because the market forces demand it.
Manufacturers with larger market share will find smaller competitors who are spontaneously compatible with any ONVIF-compliant software out there. Knowing that ONVIF will commoditize their offerings, they will need to innovate to deliver other differentiators than “our cameras work with more software than anyone else’s does.”
They will focus on many things including image quality and reliability. If functionality is offered that is not exposed via ONVIF v1.0 (the current specification), they will encourage the VMS providers to use their specific SDK allowing their products to shine.
Conversely, VMS providers with larger market share will find smaller competitors who are spontaneously compatible with any ONVIF edge device out there, and so they will not be able to differentiate on the issue of “we work with more brands of cameras.”
However, they may continue to use deep-integration via specific SDKs to key brands and models to leverage key differentiators to give them the edge — which is in the interest of the end-user. Also, they will be able to redirect R&D resources to usability, scalability, reliability and functionality, which again benefit the end-user.
It’s important to realize that ONVIF v1.0 is not the end of the road. For example, v1.0 means an IP camera or encoder can be recorded on, for example, a hybrid DVR. A VMS that allows a user to view the DVR currently uses a proprietary method such as an SDK to reach the DVR; however, v2.0 of the ONVIF specification includes among other things the ability to control playback. This means that even a regular DVR could now be ONVIF-compliant, enabling any ONVIF-compliant VMS to use and control it. It also means that IP cameras or encoders with embedded storage also become viable as an ONVIF 2.0-compliant VMS — as users will be able to view them live as well as replay video from them.
It is hard for most people to imagine that ONVIF is more than just about IP cameras. In fact, it pertains to all video-oriented devices that are on the network. Even the focus on video may broaden at some point, but whatever the direction, it will always be geared towards making networked devices work seamlessly together, and that will certainly make everyone’s life better.
Dr. Bob Banerjee is the IP video product marketing manager for Bosch Security Systems, Inc. in the Americas. He developed Bosch’s IP Resource Center found at www2.boschsecurity.us/ip and can be reached at email@example.com.
Gerard Otterspeer is the product marketing manager CCTV for Europe, Middle East and Africa at Bosch Security Systems. He has more then 10 years of experience in distribution and channel marketing in the IT industry and joined the security market in 2004. Follow him via www.twitter.com/gotterspeer1970.