THE BEST COMPRESSION, OR IS IT?

Recently at Secure Logiq we have seen an increase in the number of projects where people are requesting H.265 as their standard compression codec. H.264, H.265 and their respective smart codecs such as H.264+ are all supported by Secure Logiq hardware as the codec is about video transmission and not about the hardware components in the box. 

This document is to provide a general outline of the pros and cons of using H.265 and its smart variants. 

What is H.265?

What are the technical differences?

The three main areas where improvements have been made that allow H.265 to perform better are:

1. Block pixel referencing, meaning the codec allows same frame and other frame references, intra prediction and inter prediction respectively. 
2. H.265 allows for parallel decoding, meaning that it can take advantage of multiple cores on a CPU to process different parts of the image at the same time. 
3. Macroblock sizes are replaced with CTU’s (Coding Tree Unit). H.264’s maximum block size is 16×16 pixels (256). H.265’s maximum block size is 64×64 pixels (4096). Larger block sizes enable efficient encoding especially as the resolution increases. 

The advantages of item 3 is that the CTU can be encoded as a single block, or it can be split is smaller blocks, so where you have high detail in a scene it may be split down into 8×8 pixel areas to capture lots of detail, but where you have little detail and no movement it may remain as 64×64 pixels meaning it can encode the entire block just 1 time, thus reducing bandwidth and storage requirements. For a visual representation of this please see figure 1.For more information or a technical overview on CTU please see here or here.

So, what’s the bad news?

Whilst lower bandwidth and therefore lower storage requirements are a good thing as they either reduce the overall costs or preferably they lead to an increase in quality at the same cost, hopefully leading to no more bad crime watch images, there are other factors to take into consideration. 

IPVM.com reported in an article that the increase in processing requirements were from 50% to 300% greater than with the equivalent H.264 camera. Whilst on some hardware this would be achievable at an additional cost, from our experience we believe that most installations will need additional hardware not upgraded hardware. If you take an existing client machine with an Intel Core series processor capable of displaying 50 1080p streams at 12 FPS, you may be able to increase the CPU performance by 50% but you will never be able to increase it by 200%, you will need to double up the machines you are using. 

In recent years the use of GPU’s, called hardware acceleration/hardware decoding, in both server and client hardware has increased the VMS’s capability of handling less compression, more frames or a higher resolution. However almost no GPU’s support H.265 hardware decoding, meaning that the full load of the system will have to be put onto the CPU. For existing system this may mean that the existing hardware that is working fine, will not work if converting the cameras to H.265. 

H.265 has not been as broadly accepted by the camera and VMs manufacturers when compared to the adoption of H264. Compatibility issues still exist so you need to do extra checks to make sure that the cameras are actually going to be supported on the VMS using H.265 or H.265+.

What’s the middle ground?

The middle ground could be to fall back on to a H.264 smart codec. Through testing we found that the bandwidth savings of Axis Zip stream, which is a H.264 smart codec also called H.264+, were significant without putting a disproportionate amount of processing strain on the processing hardware. 

We recommend keeping clear of H.265 standard as H.264+ actually provides better results at a lower cost. H.265 does have the benefits of lower bandwidth but at the trade-off of much higher processing capacities. 

If you are planning on using server-side motion recording for the time being we would recommend you stay clear of H.265 altogether. 

As with all surveillance system calculations, you need to use a calculator that you trust, we have seen calculators that simply remove a fixed percentage of the requirement, which is incorrect, this is not how it works, and then do not take into account the increase in processing required. If you need help, please contact us. 

Sources used in the making of this document:

https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding

https://codesequoia.wordpress.com/2012/10/28/hevc-ctu-cu-ctb-cb-pb-and-tb/

https://ipvm.com/reports/hikvision-h265-plus

https://sonnati.wordpress.com/2014/06/20/h265-part-i-technical-overview/