H.264 is Hot: What are the Potential Problems and Risks?

[UPDATE: This article is deprecated. The H.264 has now been widely accepted for years and is the surveillance market de facto standard.

In 2013, the focus is when the move to H.265 will occur.]

Examination of H.264 risk has been far less thorough than attention to its benefits. Indeed, my own recent article examining Arecont Vision's H.264 had only minor coverage of the risks. While I still believe bandwidth and storage reduction are critical for making megapixel cameras go mainstream, real implementation issues could exist right now with H.264. As such, I wanted to lay out the potential risks. Please contribute feedback in the comments so we can better understand the issues involved.

The Risks

• What NVR systems are supporting it?
• Will the number of cameras managed per server be reduced?
• Will clients have problems with their PCs viewing the video?

Note on Standard Definition vs. High Definition (Megapixel) Cameras

The risks and the benefits of H.264 are far more critical to Megapixel cameras than they are to standard definition cameras. Megapixel cameras typically use a far less efficient CODEC than standard definition cameras (MJPEG vs MPEG4). As such, megapixel cameras have much more to gain in making the jump. At the same time, megapixel cameras have 4x to 20x the amount of pixels than a standard definition so the computing resources needed for megapixel is far greater. The strain on computing resources is the big issue for H.264 and is stressed far more by megapixel cameras.

What NVR systems support H.264?

You cannot assume that your NVR supports it simply because the camera releases support. Handling this CODEC requires your NVR to make non-trivial changes. Questions include:

• Are they supporting it now? If not, when?
• Are they supporting it for what resolutions? D1, 1 megapixel, 3 megapixel, etc?
• Are they supporting the standards based implementation or a proprietary version?

H.264 has momentum but it is still unclear how broadly and quickly that is translating into practical support and implementation.

Will the number of cameras managed per server be reduced?

NVRs often process the video as they receive it from the camera. Common uses include doing motion detection to enable motion based recording and performing video analytics.

H.264 consumes less bandwidth and storage than MJPEG by compressing the video but this compression comes at a cost (For simplicity sake, I am going to ignore the technical details here - see Axis guide to H.264 [link no longer available] for an excellent review).

Think of H.264 being like zipping files on your PC. Zipping is great for emailing and nice for storage because it takes up less space. The downside is that it can take a few seconds to a few minutes to open the zip (that is to uncompress the files). This is a little bit like what happens when you receive an H.264 video stream and you want to look at the original images. You need to unzip. Unfortunately with video, you need to unzip continuously and for each video feed. All of that can add up to significant CPU use even of today's multi-core machines.

As such, the risk and concern is how will this affect how many cameras can be managed on a server. Depending on the answer this could be a serious issue. As a community, we need clear answers on this question, especially as it relates to megapixel cameras.

Will clients have problems viewing it on their PC?

When you watch H.264 video on your PC, the displayed video on your screen has to be decoded from H.264. As such, your PC needs to be able to do the decoding. Lots of online video uses H.264 and most modern PCs don't have a problem with this. However, that's usually 1 channel and usually standard definition or 1 MP.

In a surveillance application, you often have multiple videos being displayed. Plus, with megapixel cameras, you can have a huge number of pixels to process. If all of these are H.264 and your PC needs to decode them, you could have serious usability problems. Your PC could grind to a halt or your client viewer could lock up while processing.

And of course, security users have a variety of PCs including many that are a number of years old. Older PCs with slower processors and less memory will only compound this problem. It's going to be tough to replace those PCs so you really need to make sure it works with older PCs.

What do You Think?