H.265 Is Here! Says Manufacturer Aventura

Hi All,

It's been a couple months since I read this article on CNET (Aug.22.2012) [Also, see IPVM tutorial on H.265]

Today, I received on my inbox an announcement from AventuraCCTV:

It seems H.265/HEVC cameras and DVR/NVRs are finally ready for prime time (or at least for the upcoming ASIS event on Chicago next month, I should say). Subject of the e-mail was: Visit Aventura at ASIS 2013 Booth#1532‏

Is AVENTURA the only one "making noise" with this upcoming improvement ? Which, by the way, I think is great (Full-HD videos from my 16 office cameras at high framerates on my smartphone screen finally, I hope :)


As of September 2013, Aventura is the only surveillance manufacturer claiming to ship H.265 IP cameras. They will most likely only work with Aventura's own recorders as third party support requires additional development that rivals will be reluctant to do until more manufacturers support H.265.

For background, see our H.265 tutorial.

According to AVENTURA, 50% less bandwidth and storage are NOT the only benefits. Here is the complete list:

Wow that's pretty amazing... I can't believe it requires 50% less bandwidth and 50% less bitrate. I thought for sure if it required 50% less bandwidth that the bitrate would be at least 25% more. Same for storage it really seams like if there is 50% less bandwidth and 50% less bitrate the storage would have to be at least 63% greater. According to my calculations there should be at least 77% interest in this product. I would be interested if Aventura's multicast supported 21 simultaneous client connections - oh well.

Bitrate == bandwidth

I believe undisclosed is mocking the advertisement's redundant claims, i.e., 50% less bandwidth, and 50% lower bitrate are essentially the same thing in this context.

Thanks for sharing. Clearly this is the most advanced system in the history of surveillance! :)

It's good marketing though I am not sure how close they are to actually shipping this (and which of these claims they can actually meet).

We will get in touch with them tomorrow and try to learn more.

Btw, there is a press release announcing it and a page on their website with tech specs on the H.265 cameras.

Response from Aventura:

  • The product is scheduled to ship in 30 days. They are doing longevity testing before distributing.
  • H.265 and MJPEG, no H.264 support.
  • The cameras will be ONVIF compliant, and they will provide an SDK for third party integration. At the same time, they see the cameras as a motivator to use Aventura recorders

I am stunned that they are saying that they are so close to shipping. I have not heard anyone else claim to be close on H.265. It will be interesting to see!

We'll do a formal post closer to ASIS. Aventura also says they are working on a white paper with more details.

Here is another one from IPTV world today. Announcement of a H.265 decoder. Looks like the cat is out of the bag.

That's a total sales brochure. I'll believe it when I see it. Improved DR? Improved noise levels? What does that have to do with H.265? Isn't that mostly the imager and processing chip?

Yeap, I'm also a bit skeptical. It sounds to good to be true. Besides, they claim to be ONVIF compliant, but the ONVIF Website states otherwise.

no H.264 support? Sounds just like another proprietary system, initially atleast.

I'll believe the bandwidth, storage and bitrate (which are three words for the same thing) savings when I see them. Besides, what they fail to mention are the potential negatives, likely including lower frame rates. H.265 requires more horsepower, especially on the encode side. I seriously doubt they will be able to maintain high frame rates from the current crop of chips. After all, many current cameras have trouble doing full 30fps on two h.264 streams.

Most of the claims for H.265 are not true, although H.265 is better than H.264 and has some improvements.

Louis, can you expand? Which claims are not true? How do you know?

h.265 is producing video file sizes at about half the size of h.264 for the same comparable quality video. One of the biggest drawback with h.265 is the computational requirements are about 5 to 10 times greater then h.264.

I don't see any cctv manufactures jumping on the h.265 band wagon very quick as most CCTV companies are having a hard enough time supporting full frame rates, multi streaming and on board analytics in the camera with the power consumption limitations of poe. You can't exactly run a intel core i7 cpu off of 30watts of power.

Check out some real world benchmarks.

Tomshardware has also done a piece on h.265 along with anandtech.

As for how AventuraCCTV is doing it with there cameras they must be sacrificing other features to get the h.265 encoding done within the power limitations of the dsp's/cpu's available for cameras in today's markets.

There is a fundamental problem with video compression systems for surveillance purposes. Video compression solutions are developed primarily for broadcast purposes. In the broadcast world the horsepower required to compress is of little relevance, as it only needs to be done once (to generate the program for broadcast). The decompression and rendering is done millions of times in millions of set-top boxes - and usually only one stream at a time.

Surveillance requirements are quite different. We require to compress hundreds, perhaps thousands of channels (i.e. however many cameras you have), so the horsepower to compress really matters - this is what makes IP cameras expensive. Most channels are simply recorded and typically 97% of that recorded video is never viewed and is therefore never decompressed.

Another difference in surveillance is that for a live-monitored system, we require to decompress many video channels at once (for a video wall for example) and as we all know, this requires a great deal of PC horsepower and does cause issues (such as image stutter and dropped frames) when systems are trying to display many mega-pixel camera streams at the same time.

What we really need is a video compression system designed from the ground up for surveillance purposes, taking into account specific requirements like high-noise low-light environments, frequent fixed image backgrounds, minimum motion blur and taking account of evidential integrity aspects too.

It would need an organisation like ONVIF or something similar to establish any new compression technology as a standard, but who would develop it in the first place ? It would have to be some sort of open source movement, but I'm not sure the market is big enough to generate the interest in doing such a project.

So it looks like we'll just have to accept whatever the mainstream broadcast industry develops for itself and adapt it as best we can to surveillance needs, as this is what we have always done.

H265 is fine for recording the megapixel stream and the MJPEG low resolution stream is good for live view in multi camera grids.

Regarding encoding - its done by the camera using an ASIC so can be made low power and efficient unlike using x86 CPUs on a PC.

In fact, I don't understand why many cameras have discontinued MPEG4 ASF because that is probably the best for live view at low CPU.

The dome and box from Adventura have the same shape as current Hikvision H264 models - can someone find out if Hikvision is releasing H265 models?

Also I assume you only get 50% compression efficiency improvement if it H265 High Profile? Are these cameras Baseline, Main or High?

I am also concerned about picture delay - I have seen some cameras that exhibit increased delay when using H264 High Profile vs Baseline (from ~150ms to ~400ms).

Aventura == Hikvision (with a little extra GUI coding and some hardware rebranding)

There were a signifiant number of manufacturers at this years Infocomm with H.265 offerings for teleconference applications so I do not doubt that this will be adopted. Clear benefits in bandwidth and storage for megapixel cameras.

After lookign at IPVM report from ASIS, and the H265 camera able to handle 3MP video at 20 fps with only 1Mbps, it seems very interesting! It´s worth the wait for an IPVM test on this