H.265 / HEVC Codec Tutorial

By IPVM Team, Published Jan 08, 2019, 12:09pm EST

H.265 support has improved significantly since its introduction, with H.265 camera/VMS compatibility increased compared to only a year ago, and most manufacturers shipping H.265 models.

However, there are still challenges impacting H.265's competitiveness and compatibility, keeping it from replacing H.264 in the mainstream.

In this report, we review all these issues, including:

  • H.264 vs H.265 Technical Comparisons
  • Impacts On Quality
  • Barriers in Moving to H.265
  • Camera/VMS Compatibility Improvements
  • VMS Support Reviewed
  • ONVIF Conformance Delays
  • H.265 vs Smart H.264
  • H.265 Smart Codecs
  • H.265 IPVM Test Results
  • H.265 CPU Load Impact
  • Patent Licensing Issues
  • Usage Recommendations

Overall, the key marketing claims for HEVC/H.265 is reducing bit rate requirements in half to deliver the same quality. For instance, if a 1080p / 30fps H.264 camera required 4Mb/s, the equivalent H.265 camera would be expected to require only 2Mb/s. But that is now, clearly not enough, as we will explain inside.

*** **********, *** ************* **** ****/*.*** **********. *** *** **** details, *** ********** **** ***** ******** document(***+ *****).

Technical **********

***** **** ********** ************ drive *.***'* ********* *********** gains:

  • **** ****** **** ******* of ***********: ***** *.***'* maximum ***** **** ** 256 ****** (** ***), H.265's **** ** *** greater ** **** (** x **). ********** *** the ****** **** ******* more ********* ********, ********** for ****** ********** ******. Read * **** ********* blog **** ***** *******. *** ***** ***** shows ****:

  • ******** ******** ** *.*** will ***** ********* ***** of *** ***** ** be ********* **************. **** can ***** ** ******** and **** ********* ** the ************ ****** *****-**** CPUs *********. *.*** *** not ******* ****.
  • "***** ****** ******" ****** has **** ***** ** H.265 **** "******* ******** without ******* ** ****** any ******** **** ******** earlier ** *** *********, supporting ** ********* ******** coding ***** ***** ** 'open ***' *********" (******* * ** **** document). **** ***** ** a ********* ******* *** surveillance ** *** **** to ******** ******** ***** has ****** ******** * frames **** *** ******** increase *** ****.

*** ***** ******* **** H.265 *****, **** **** H.264, ** ******** ********. While ** ****** ** planned (**** ** *.***), H.265 ** ******** ** bring ******** ***** ** surveillance. *** ******** ******* streaming ** *** ********* clients *** ****** ******* pruning.

Potential ************ ** *******

* ****** ** ************* tout ************ ** ***** quality **** *.***, ****** this ** **********. *.*** is *** ********** ****** 'quality' **** *.*** *** was *.*** ****** '*******' than ****-*. ** ****, if *** *** ***** appropriate ********* *** *.*** for ******* *****, ****** to *.*** ** ******** to ******* ***** *******. However, ** *** ****** bit ****. *** **** case ***** ** ***** indirectly ************** ** ** ********* levels **** *.*** **** set ** *** ** to ******** ******* *********. Then, * ****** ** H.265 ** *** **** bandwidth ***** ***** ******* quality.

Barriers ** ****** ** *.***

****** ** *.*** *** not **** ****** ** easy *** ************ *** to ***** *** ********:

  • *** *******: ******** ******* ****** simply ** ******** ** H.265 *** ********, ** new ******** *** ********* required, ******* **** ******* must ** ******** **** as *** ******** **** moving **** ****-* ** H.264.
  • *** *** ********: ***** *.*** ** a ***(**) ********, *** vendors **** ** *** support. ***** ** ******** a **** ****** ** work *** *******. ** such ****** *** ****** until ***** *** ******* camera ********** (*** *** support *****).
  • ********* ********** *****: *** ******** ** bandwidth ********* ** ****** processing ***** ************ **** projections ** ******** **** 50% ** ***% ********. On *** ***** ****, decreased ********* ************ ***** actually **** ************ ***** as ** ******* */* transfer ****. **********, **** should ** ** *** there **** ** ************** concerns *** ****** ** test *** ******** *** issues.

Camera ******* **********

********** ****, *.*** ******* in ** ******* *** NVRs ********** *************, **** Asian ****** **** ** including ***** [**** ** longer *********],******,*********,*******, ****************** *.*** ** **** models, ***** ****** **** as ****, *****, **************** ******* *.*** ******, with **** *** ******** including *** *****. *******, latecomers **** ** *******, Avigilon, *** ***** **** all ********* ***/** ******** H.265 ******.

VMS/Camera ************* ********

*.*** ***/****** ************* *** improved *************, **** **** camera ************* (****, *****, Hanwha, *********, *********, *******, etc.) ****** ** ****** VMSes **** *.*** ******* (Exacq, *******, *********, *********) with ** ************* ******** aside **** ********* *.*** instead ** *.*** ** streaming *****.

**** * **** ******* (~mid ****), **** *** not *** ****, **** most ***** ********** **** limited ****** ** ********* additional *** ** ***** or ****** ************* ** the ****** ***** *** web ********* ** *** H.265 *******.

***** ************ ** *********** and **** ** *** are ****** ** ******** to ***** *.*** ******** further.

VMS ******* **********

** *** *** ****, many ********** *** ******* support *** ** ***** some *.*** *******, **** direct ****** ******* *** most ** *** ****** models ********* *****. ** of ***** ****:

  • ******** ******* ******: ******** *******, ** well ** **** ****** via *****.
  • ***** ****: *****, ******, *********, Panasonic, *******, ******* **** (and **** ***** ****)
  • ***********: ******** *************, ********* Axis, *****, *****, ******, Hikvision, ********, **********, *******, ONVIF, *** ******* ****
  • ******* ******** ******: **** *************, ********* Axis, *****, *****, ****, Hanwha, *********, ***, *******
  • ********* ********: *******, ****, *****, Dahua, *-****, ******, *********, Illustra, **********, *********, *********, TVT, *******, ******* (*** OEMs) *** ******.
  • ******* ***** *********: *****, *********, ******, Hikvision, *****, *********, *********, TVT, *******, ******* (*** OEMS) *** ****.

H.265 ***** *********** *** ********, ******* * ********

*** ** *** ***** Profile * ** **********, a *** ******* *** required ** ******* *.***, named ******* *, ******** in ** ****. ***** to **** *******, ***** could *** ********* ***** compatibility **** ***** *.***, even ** **** *** camera *** *** **** Profile * **********. *** our ********* *** **** ***** Will ******* *.****** **** *******.

******* ******/*** ********* **** included ******* *** *.*** via ***** (*** ******* conformance **********). *** *******, Milestone ******** ***** ******* for *.*** ***** ******* in ***** ********* ****** list, ** ** ***** and ******* *****.

*******, **** *** ******* of ******* *, *.*** is *** ********* ** a *****-**-*** ***** ****** in ********** *******, ******* that ******* **** ******* it *** *** ** the *** ** *********, and ***** **** ** able ** ******** ****** and ******* **** ******. With **** ****** ** place, ******* * *.*** cameras************* *********** ** ******* S *.** *******. *** our***** ******* * *********** **** *******.

Smart *.*** ** *.***

*.*** ** *** *** only ********* ******** ********** being ******* *** ***** surveillance *******. ******, ** the **** *** *****,***** ********** **** **********, ********** significant ********* ********** ******** to ******** *.***, *** reducing *** ********** ** move ** *.***.

*.*** ***** ****** **** 2 *** ******** **. H.265:

  • ********* **********/***** **** *.***, eliminating *** **** *** new *** ******* *** CPU **** *********
  • ******* * ***** ******** with ***** *.*** *** significantly ****** ********* ***********, a ******* **** "*******" H.265 *****.

** ********** ** **** ***** codec *********, *** ********* ******* there **** *** ******* than **** *** ********** marketing ****** ** '***-*****' H.265.

H.265 ********* **** ***** ******

**** ***** ****, "*******" H.265 ******* *** ************ rare, **** ************* ******* implementing *.*** ***** **** smart ******, **** *********** *.***+,****** *.*** **** **********,******* *.***/***** ****** **, ***. **** *********** offers ****** ************, *** as ******* ** ********** with *.*** ***** ****** on ** ***. *******, for ******** ****** ********, this ** ****** ** be *** *********** **** moving *******, ********** ** H.265's ******* ********** *****.

H.265 **** *******

** ***** *****, *.*** cameras *** *** ******* material ********* ************/******* **** typical *.*** ******* (****.*** ** ******* ** H.264 **** *******), **** *.*** ***** codecs ********* ****** ******* than "*******" *.***.

*******, ** **** ****** tests, **** ********'* ******* * *******(*********** ******'* ****** ********** of *.*** *******), ***** H.265 ******** **** ******* lower **** ***** *.***, both ** *** **** camera *** ****** ***********.

bandwidth comparison

*.*** *** ******* ** it ******* *** ********** generations ** ***** ****** available, ******* ** *.*** improvements **** ****.

CPU **** ******

** *** *****, ******* H.265 *** ******* **** processor *********, ******** ********* double *** *** **** of *.*** *******. ******* of ****, ***** ****** be*********** ** ******** ****** CPUs ** ****** ********, since ***** *** **** equipment ** ******* ******* using *.*** *** ** insufficient.

*** *******, **** ************ *.***+ **** ******, *.*** ******* **** more **** ****** *** CPU **** ** *.***, both *** *** *****.

cpu load comparison

*********** **** *****, ***** hardware/GPU ******** *** ****** more ****** ** *** past ******* *****, **** GPUs ** *** ******* H.265 ******** ********. ******* of ****, ***** **** may ** ******* **** offloading ** *** *** when ***** *.***, ***** settings **** ** ****** on *.*** ****, ***** below:

hardware acceleration impact

H.265 ****** ********* ******

*.*** *** ********** * new ************ *** *************: patent *********. ****** *.***, which *** **** * single ****** ****** (******), H.265 ** ******* ** 1,000+ ******* **** ** multiple ****** (******, **** Advance, *****, *** ****). Because ** ****, ***** is ********* ***** ************* about ***** ***** ** patents **** ****** ******* for ***** ********.

** * ******, * number ** ****** *************/*** developers **** *** ******** their ******** ** *** (below). ***** ****** *** covered ** **** ****** in **************** ******** ********** *.*** Products ******.

Usage ***************

***** ** *** *** above *******, ** *********:

  • ******** *.*** **** ***** codecs, ***** *.*** ******* smart ******, ***** ******* smart ******, *.*** ******** more ********* **** ***** H.264. ****, *.*** *** general ****** ** ***** VMS ******* *** ****** decoder *** **** *** present ** *.***.
  • ****** **** ***** *.*** cameras *** ******** **** work **** **** *** / *** ** ******. Though ********, **** ************ will ***** *** **** today *** ***** ****** a ***** *******.
  • ****** **** *** **** sufficient ********** ***** **** on *** ********* ****** (if *.*., *** ******** is ***** ****** ***** motion ********* ** ***** display) *** ** *** client **** ** ****** that *** ****** *** sufficient ********* ** ****** and ******* *.*** ******* losing ****** ** ***** quality.

****: **** ******** *** originally ******* ** **** but ******* ** ****, 2017, **** ** ******* advances/changes ** *.*** ******* and ***********.

Comments (20)

John,

Per other IPVM reports on Smart CODECS, they are most useful on scenes where there is very little motion content.  Any motion in the scene will push a bitrate higher.

I propose a test where you have a busy scene or a selection of varying motion content between 10% and 75%.... and compare the H264 SMART CODEC to a vanilla H265.

Hey Mike, we'll be doing more testing of this coming up, but as a recent example from testing done for the Hikvision H.265+ Test, vanilla H.265 was higher than smart codec H.264+ by far in the higher motion scene tested (a heavily foliaged fenceline on a windy day, about 40-50% of the scene was moving). 

On the 4K model, H.264+ was ~2 Mb/s, H.265 was over 7.

At 1080p, H.264+ was ~300 Kb/s, H.265 was ~3 Mb/s. 

We'll be doing more with this, but from what I've seen, I'm going to say that smart codec H.264 is likely to be lower bitrate than H.265 in the vast majority of scenes (not to mention lower CPU load to decode). 

Also, it's getting to be a moot point, since most manufacturers moving to H.265 are offering smart codecs with it, anyway (Dahua, Hanwha, Hikvision, Panasonic, Vivotek, etc.).

Very good data John, thank you.  I have two big wishes about the future adoption of H.265:

1)  That the manufacturers keep to the "standard" and quit putting their own little twists on their interpretation that keeps their equipment from fully working properly with everyone else.  I know this is a super pipe dream, they want to do everything they can to encourage people to buy their equipment end-to-end and not piece things together.

2)  Adoption of H.265 into HTML5.  This HAS to be done!  Please think about it, we're down to one browser now that is actually probably going to reach its end of life before too awful long.  When the browsers stopped supporting NPAPI plug-ins, the only reaction from security manufactures that I received was "oh well, use Internet Explorer".  Since MS is starting to get some better performance out of its Edge browser, how long before they dump IE entirely and now the whole security industry's only answer is to load outdated browsers that allow NPAPI plug-ins or work with ActiveX plug-ins from 10 years ago in a browser that has to end eventually.  I honestly and truly cannot for the life of me understand why this gets ignored.  Mention HTML5 to your manufacturer and wait for their hmmming and hawwing about "we're working on it" meaning "we're waiting for one person to develop it so we can all 'share' it".  It solves so many problems including browser and device independence.

 

VP9 solves the plugin issue.  VP9 is the obvious choice for native browser decoding moving forward and is royalty free.  It's our hope Axis continues to be a leader and offers VP9 in the near future.  https://en.wikipedia.org/wiki/VP9

That really looks good!!!  I will contact a few manufacturers to see if they have even heard of it yet.

I suspect most manufacturers will find it easier to pay for H.265 / HEVC licenses or ignore those licenses completely, betting that most users will not care.

But them paying for licensing still does not provide an answer from the manufacturers about adapting to a "modern" web browser.  It also leads me to think that they we will still have individual manufacturers versions of H.265 with minimal interoperability.

Agree, especially about the second point. 

We as a VMS manufacture facing the issue: if the camera streams H.265, and we need to display it in the browser, the server needs to do transcoding to VP8/VP9.

For the enterprise customers(few thousand users and good portion of them need web, not a thick client) it's a big challenge: could be too much transcoding for the servers. We even had to introduce a system option how much transcoding is allowed, so there is a way for admins to control it. 

Here is the current browser support status https://caniuse.com/#feat=hevc

Thank you for sharing your thought. Could you elaborate on the enterprise customers' need for the web? When is the cases where you need to display it in the browser, and how often that happens?

I agree with your suggestion as for the second issue. Notably, Hanwha Techwin's Wisenet cameras are supporting plug-in free streaming for not only H.264 but also H.265. That being said, you can live view or play back in any web broweser such as Chrome, Edge, Safari, Firefox for H.265 streaming.

You can find more details at https://www.hanwha-security.com/en/technical-guides/white-papers/?seq=13&menuCd=MN000230&srchTemp=

My cloudy and cracked crystal ball foresees a possibility that manufacturers and users ultimately end up forgoing H265 in favor of waiting for when a codec with scaling (SVC) is widely available and suppotred. With smart streaming making a significant impact on bandwidth and storage becoming continually cheaper, and the challenges of "vanilla H265" in processing power, is there really an urgent need to move to H265...?

forgoing H265 in favor of waiting for when a codec with scaling (SVC) is widely available and suppotred

But will it ever happen? Scalable codecs for video surveillance have been discussed for many, many years but it's never been more than a niche. To be clear, theoretically there is value of having a single high resolution / fps stream that can be segmented into multiple lower resolution / fps streams but, my understanding, is that the overhead to support that (i.e. higher bandwidth for the scalable stream) has historically made it unattractive.

Well, when H.269 comes out I think both parties will be satisfied simultaneously. Just a thought while arguing with my wife on camera bandwidth estimating.

According to Hikvision's white paper,

http://www.hikvision.com/upload/20161209211521855.pdf

I think there are some techniques used in smart encoding.

And some idea should be similar to this proposal

M. Pettersson, J. Samuelsson and R. Sjöberg, HLS: Dependent RAP indication SEI message, JCTVC-S0095, Strasbourg, France, Oct. 2014

 

Interesting article

Just to mention, Digifort supports H.265 for about 1 year and a half now with the following supported brands (Not in order): Hunt, MTW, Dynacolor, Geovision, Dahua, Uniview, Tiandy, Infinova, AVTech, Siqura, 3S, Wama, Vivotek, Hikvision, Vitek, Saten, Squilla, Axis, LecVox, TVT, Sunell, Samsung, Milesight

But I guess some of these brands are OEMs

Our findings are similar to yours, just on the CPU load we haven't noticed 100% increase in usage but rather something between 10 and maximum 50% more, that will depend on how much motion is on the scene. Also offloading to the GPU with QuickSync does not necessarily improves on the decoding too much, but still we can see some gains, although I still prefer software decoding

I'd be keen to see more examples in multiple lighting conditions, as it would really help show off the advantages of H.265, or disadvantages at the very least.

 

Interestingly, when the hardware acceleration was on, it made no reportable difference. I would have thought this would have some difference, if only by 0.1%

While the storage and bandwidth benefits for H.265 are great, we most often have to revert to H.264 streams as 9-16 H.265 streams will slow most user client machines to crawl.  While most sites do not mind buying a beefier client computer for a dedicated guard workstation they are less willing to buy new machines for the other 5-10 people who are also users.  This essentially makes H.265 a negative for us.

NOTICE: This comment has been moved to its own discussion: H.265 Storage And BW Benefits Great, But We Most Often Revert To H.264

Good to be aware of informative

Read this IPVM report for free.

This article is part of IPVM's 6,653 reports, 896 tests and is only available to members. To get a one-time preview of our work, enter your work email to access the full article.

Already a member? Login here | Join now
Loading Related Reports