Standards in IP Video

To grow the pie, standards are needed; imagine if all web servers had slightly proprietary protocols, so that you needed an Apache client if you connected to an Apache server, and another for IIS servers. What if you couldn’t move the HTML from the old IIS to the new Apache? Imagine if for every new version of IIS you needed to re-write parts of the HTML, and distribute a new client to all the users.

In broadcast video we have NTSC, PAL and SECAM and a bunch of variations of these, yet TV has attained omnipresence. But the standards have been stable for many years, while it seems as if our industry have a different protocol for each camera, and even different versions of the same camera.

There are 2 big movements to try and define a standard. One is driven by the NVR side, and the other by the big camera manufacturers. I believe the odds are with ONVIF, if they can enforce an element of dictatorship and avoid designing another camel*.

A winner must emerge for the benefit of the consumer. Even 4 different standards would be acceptable, and allow NVR companies to focus on what matters to the end user. Stability, flexibility, ease of use, useful features that improve security, and increases the efficiency of the staff. In the ideal situation, a client would simply buy a conforming camera and plug it in, with the certainty that it would “just work”.

There are roughly 3 areas of interoperability that must be addressed.

  • Discovery and Capability
  • Video and Audio formats
  • IOs

Discovery is partially addressed by uPNP and to some extent ARP and DCHP sniffing can be helpful on LANs. But for remote cameras, a simple XML response to a fixed address would suffice.

Video and Audio formats are standardized, but some manufacturers provide proprietary versions of various codecs (Mobotix has a proprietary JPEG codec for example). I suggested a couple of years ago that we define a reference decoder for each format – I am not sure it was ever done – but if the video or audio cannot be decoded by the reference decoder the camera should not be considered conforming.

A standardized way for cameras to notify an NVR of the closure of an input, and a way to manipulate a relay would also be needed.

On top of all this comes the need for standardized authentication and encryption schemes (trivial), but that is beyond the scope of this humble blog.

As an example, the current ONVIF core spec is 223 pages and is based on SOAP, which makes it relatively simple to use in modern languages – if a little bloated;

HTTP/1.1 500 Internal Server Error
CONTENT-LENGTH: bytes in body
CONTENT-TYPE: application/soap+xml; charset=”utf-8”
DATE: when response was generated
<?xml version=”1.0” ?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
xmlns:ter="http://www.onvif.org/ver10/error"
xmlns:xs="http://www.w3.org/2000/10/XMLSchema">
<soapenv:Body>
  <soapenv:Fault>
    <soapenv:Code>
      <soapenv:Value>fault code </soapenv:Value>
      <soapenv:Subcode>
          <soapenv:Value>ter:fault subcode</soapenv:Value>
          <soapenv:Subcode>
             <soapenv:Value>ter:fault subcode</soapenv:Value>
          </soapenv:Subcode>
      </soapenv:Subcode>
    </soapenv:Code>
    <soapenv:Reason>
      <soapenv:Text xml:lang="en">fault reason</soapenv:Text>
    </soapenv:Reason>
    <soapenv:Node>http://www.w3.org/2003/05/soap-envelope/node/ultimateReceiver</soapenv:Node>
    <soapenv:Role>http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver</soapenv:Role>
    <soapenv:Detail>
       <soapenv:Text>fault detail</soapenv:Text>
    </soapenv:Detail>
  </soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>

The long message contains just 5 chunks of useful information; fault code (most likely a number), reason (“not supported”) and details (“don’t do this again”). The rest is called “envelope” – that is one giant envelope for such a small message 🙂

Even if I have my peeves about SOAP and its bloatedness, it is MILES better to have a standard than 236 different ways to get an error code from a camera.

Regardless of who defines the standard, the end user will be the winner. We will then have to compete on different parameters, and I can’t wait for that to happen.

*a camel is a horse designed by committee

Advertisements
Tagged , ,

One thought on “Standards in IP Video

  1. Thanks for the fact and opinion. Great to see this kind of discourse in our industry–it’s needed.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: