IP Camera Manufacturer Compression Comparison

By: Ethan Ace, Published on Nov 27, 2017

Despite the use of standards-based video compression (H.264/H.265), our tests show that default image quality settings for different manufacturers vary widely, with no standards for terminology or scale used. This can result in two cameras with the same resolution produced by two different manufacturers producing widely different out-of-the-box results.

To help clear this confusion, IPVM has analyzed cameras from 10 manufacturers and answered these key questions:

What is the real H.264 and/or H265 quantization level for each camera manufacturer's default settings? How do they vary? Who defaults the lowest and highest?
To normalize the H.264/H.265 quantization levels so that each manufacturer had the same compression, what camera settings should be used?
What is the impact of bandwidth as H.264/H.265 quantization/compression levels are varied for different manufacturers?
What impact do smart codecs have on these settings?

Here is what we found for default settings from these manufacturers, showing manufacturer with the highest default compression (Bosch), 50% higher than the manufacturer with the lowest default compression (Arecont):

If you really care about image quality and optimizing bandwidth / storage use, this is a critical report.

******* *** *** ** *********-***** video *********** (*.***/*.***), *** tests **** **** ******* ***** quality ******** *** ********* manufacturers **** ******, **** no ********* *** *********** or ***** ****. **** can ****** ** *** cameras **** *** **** resolution ******** ** *** different ************* ********* ****** ********* out-of-the-box *******.

** **** ***** **** confusion, **** *** ******** ******* from ** ************* *** answered ***** *** *********:

**** ** *** **** H.264 ***/** **** ************ level *** **** ****** manufacturer's ******* ********? *** do **** ****? *** defaults *** ****** *** highest?
** ********* *** *.***/*.*** quantization ****** ** **** each ************ *** *** same ***********, **** ****** settings ****** ** ****?
**** ** *** ****** of ********* ** *.***/*.*** quantization/compression ****** *** ****** for ********* *************?
**** ****** ** ***** ****** **** ** ***** ********?

**** ** **** ** ***** for ******* ******** **** these *************, ******* ************ **** the ******* ******* *********** (Bosch), **% ****** **** the ************ **** *** lowest ******* *********** (*******):

** *** ****** **** about ***** ******* *** optimizing ********* / ******* use, **** ** * critical ******.

[***************]

Key ********

**** *** *** *** findings **** **** ****:

******* ******* ************:***** ** *** *****, average ******* ************ ** ~25, **** ******* ******* widely, **** ~** ** 30.
*.*** ************ ****** ******* to *.***:******* ******** *************' *.*** cameras, ** ***** **** quantization *** ************* ******* when ***** *.*** *** H.264, ****** ********* *** notably ***** ***** *.***.
****** ********* ******: ** * **** ** thumb, ***** **** ****** compressed *** ** **** average *** ******** ** a **-** ********* ********, varying ** ************. *** to *** *** * roughly **-*** ********.
** *********** ******* *************:** *** ** ************* tested, **** **** *** same ****** *********** *** scale, *** *** ******* terms (**** ** "******") result ** ******* ************ levels.

Video *********** ********

************* ***********, *** *** manufacturers *** ** **** actual ************ ***** ********, is **** *********. ******************* *** *********, *********** is ******** *** *** be * ****** ****** -**** *** ******* *** bandwidth.

*** ************ ***** ** compressed, ********** ** **********. And, **** ** *** cameras **** *** **** resolution, ***** *********** ****** can ** **** ********* (see *** ***** ******* / *********** Tutorial *** **** **********).

**********, *********** ** *.*** and *.*** ** ************ on * ***** ** 0 ** **, ****** quantization, ** ***** ** the ***** *****:

*******, ****** ************* ****** never ******** **** ************ levels ***** ******* ***. Instead, **** *** * variety ** ****** *** naming *******. *** *******, **** is **** ** ************* refer ** ***** *********** settings **:

** * ******, *** *************' cameras might **** *** **** resolution *** ************* ********* compression ******, *** ********* varying ***** ******* *** bandwidth ***********.

Average ******* ************: ~**

***** ** ****** ******** of **+ ******* **** these ** *************, ** found ******** ***** ** the ***** *****.

******* ******* ************ ***** was ** **** * range ** ** ** **.
******* ******* ********* ** the ****** ************ ** all ******* ****** ** Q20, **** ********* *** Uniview ***** ** **.
*** ******* ******* ************ was *****, ************* *** by *******.

Terminology ***********

**** ** *** ************* tested **** *********** ** scales ***** ****** *** directly ********** ** ***** manufacturers. **** *** ***** confusion **** ****** ** standardize ******** ******* ** one ************ *****.

*******, ****** *** **** different ****** ********* ** the ************, ****** ******** even **** *********. *** example, ******* *** ***** a ********* *****, ***** and **** **** **** Q ******/***** ******* **** compression ** *** ** "1", ***** ********, ****, and *****, **** *** Q ******/****** ******* **** compression *** ****** ** "1".

Normalizing ***********

** **** ********** **** camera's *********** ******** ** achieve * ************ ** ~28. **** *** ** useful *** ***** ******* to ********* *********** ******** on ***** *** *******, acting ** * ***** for ******* ****** **** the **** ************.

**** **** ***** *** vast ******** ** ******* allow ***** ** ******** adjust *********** ********, ***** are **** **********. *** *******, new ********** ****** *** Sony ******* **** ******* a ***-******** *** ************** which **** *** *** compression *** ******* **** only * ******* ****** and/or ***, **** *********** and ******* **** *******. See *** ****** **** *** ******* ******** VBR.

Quantization ************* ******* ***** *.***

***** ** *** ***** of ******** *************' *******, ******* and ************ ************ ****** were ************* ******* **** using **** *.*** *** H.265, ******** ******** **** notably ***** ** *.*** streams, ********* **-**%. ******* should *** *** *.*** / **** ***** Tutorial **** *** **** ***********.

Compression ****** ** *********

********* ** ******** ******** by ************ *****. ** demonstrate ****, **** ******** quantization **** * ******** of *** (****** **********) to * **** ******* Q28, ******** ** * lower *********** ***.

***** ** ***** *****, we *****:

Q35 ** ***: Changing quantization from Q34 to Q28 resulted in a 3x-5x bandwidth increase on cameras tested (Axis, Dahua, Hikvision, Panasonic).
Q36 ** ***: Changing from Q35 to Q22 resulted in drastic increases, ranging from about 5x to 11x, depending on manufacturer.

Smart ***** ******

*** **************** ********* ***** apply **** **** ***** codecs *** ****** *** or *** *********. ** nature, ***** **** ****** quantization *********** ***** ** objects ** *** ***** instead ** ********* ** on *** ****** *****, smart ****** *** **** difficult, ** *** **********, to ***********.

************, ************ ****** ** smart ***** ******* *** typically **** ****, **+, since **** ** **** scenes ** ******** ** static ********** *** ********* more ****** **********, **** only ****** ******* ********* average ** ***** ***********.

*** *******, ****, *****, *** Vivotek ********* ** ***** codecs ******* ** *** tests, *** *** ***** averaged ** ** ****** quantization:

******* ****** *** *** ***** ***** ***** *** **** ******* ** these ******** *** ******* issues.

Setting *********** *** ********* *******

***** ** **** *********** settings *** **** *************' cameras, **** ***** ********* defaults *** *************.

*******

******* ** *** ** few ************* ** ******** use *** ************ ***** in ***** *** *********. Quantization ** ********** **** 16 ** **, ********** to **.

********

********'* *********** ******** *** be ******* ***** *** compression *** ***** **** tab ** ***** *** UI, *** ** **** a ******* ****** ** "1" (****** ***********) ** "20" (******* ***********). ******* ******** to "*", ***** ** quantization.

****

**** ********* **** *** different *** **********, ** many ** ***** ******* have *** *** ************ to ******** ***** ***** **. **** *** *** old *** *** ******* to *** **** ********: ** compression. *** *** *** interface **** * ******/****** entry:

***** *** *** ********* simply ****** **** *****:

*****

*****'* ***** ***** ***** quantization ** *-******, **** I-frames ******* ** **** by * ******** ****** ("I/P-frame ***** **" *****). To *********** ** ******* 28Q, ***** ****** *** "Min. *-***** **" ** 26, *** *** */*-***** delta ** *.

*****

*****'* *********** ******** *** found ** *** ***** tab, *** *** "*******" can ** *** ******* "1" (**** ***********) ** "6" (***** ***********), **** 2 ******** ** ~** quantization ** **** ****** ******.

*********

*********'* *********** ******** *** under *** *****/***** ***, ** a ***** ** "******" (**** compression) ** "*******" (***** compression), ********** ** "******." Based ** *** ***** of ******** ********* ******, "Medium" ******* ** ~***.

******/*******

*** ***** ****** ******* do *** ******* *** way ** *** *********** of *** ******, **** both ******* *** ************ varying. *** **** *******, see *** ****** **** *** ******* ******** VBR.

***** ****** (******* ***/****) include *********** ** * scale **** "**** (*)" (***** compressed) ** "***** (**)" (most **********), ********** ** 4. ***** ****** ****** be *** ** ~** on **** ***** *** average ** ************.

*********

** ***** ** ****** image ******* ** ********* models, ***** ****** *** transmission ******** ** *** (defaults ** ***** ****). Image ******* ** ******** on * ***** ** 0-9 (***** **** ** Low), ********** ** * (Normal), **** * ******* quantization **.

**** **** ** ******* tested, *********'* *** ******* series **** *** **** models ***** ********* ** H.265, ***** *****.

****

** **** ***/*** *** video ***** ********, *********** ** *** in *** "***** ******* 1: ******** ****, ***** ranges **** "*" (**** compressed) ** "**" (**** compressed), ********** ** * (roughly ***).

**** **** ******* ** Hanwha, ****'* *** *** cameras ** *** ***** compression ** ** ***** to * *** *****. See **** *** ******* ******** VBR *** **** *******.

*******

******* ******* **** ***** quality ** * ****** ranging **** ****** "*******" to "*** ****", **** no ****** ** ******** enter * *****. *** slider ****** ** *** to ~*/* ** *** way ****** *** **** for ~***.

*******

*******'* *********** ******* ** named "****** *******", ***** below, **** * ***** of "******" (*****) ** "Excellent" (****). "****" ****** be **** *** ************ ~28.

Test ********

***** ******* **** ******, you ****** ** **** to ****** *** * ********* on **** ****.

[****: **** ****** *** originally ********* ** **** and ************* ******* ** 2017]

Comments (14)

Undisclosed Manufacturer #1

11/27/17 07:01pm

Great report! Can you elaborate on the impact of altering P frame interval (or some say, I frame interval or keyframe interval)? Is there any significant relationship between keyframe interval and quantization? Clearly the shorter the time between P frames, the higher the bandwidth but what are the other impacts on the video? It's another opportunity for confusion on which way the scale goes and its impact on quality and bandwidth. Thanks!

Ethan Ace

IPVM | In reply to Undisclosed Manufacturer #1 | 11/27/17 07:45pm

We have a report on P-frame/I-frame impact here.

In general, P and I frames don't directly impact quantization levels. They will impact the visual artifacts in video, though. So when I-frame interval is long, you'll see trails form behind moving objects, and additional noise throughout the image until the next I-frame. Conversely, when I-frames are close, you'll see less of this issue, but there is generally not much of a practical improvement from intervals shorter than a second.

This video from our test shows I-frame intervals varying from long to short.

Undisclosed Manufacturer #2

In reply to Ethan Ace | 11/27/17 11:37pm

Hi Guys

You've used the term "artifacting" - but it looks more like motion blur. Did you have the shutter speed at default (usually 1/30 or 1/60 sec)? This is probably not a fast enough shutter speed to stop motion blur - even in this scenario.

By the way - really enjoy reading your reviews, commentary on the industry, etc. - keep up the good work.

Cheers

Ethan Ace

IPVM | In reply to Undisclosed Manufacturer #2 | 11/27/17 11:50pm

There is definitely some blur present in those videos, yes, but we specifically are calling out issues with artifacts.

We show the trails of compression artifacts behind the train, e.g.:

Sergey Bystrov

NetworkOptix
11/27/17 09:13pm

Besides quantization levels, final image quality would depend on:
- spatial filter
- temporal filter
- motion vectors search( a type of macroblocks)

- motion vectors search( accuracy: pixel, half a pixel, quarter pixel etc )

- macroblocks type selection

- CBAC vs CAVLC

- bitrate control( how well does it handle changes)

- etc

Quantization parameters is a small part of the overall equation, and making some conclusions based on it is likely misleading.

If I would explore how advanced codecs are from different vendors, I would analyze other parameters as well: so you can see that this vendor uses macroblocks of such type, motion vectors of such accuracy etc... I know nobody would be interested in reading:-)

But only real criteria of image quality/bitrate is subjective "I like it more" or "I like it less", not quantization by itself.

Ashley Schofield

11/28/17 12:31am

Great report, but curious to know the firmware versions tested of each camera.

Cheers

Franky Lam

RICOH (HONG KONG) LTD
11/28/17 01:55am

Details report and end-user must always care about the bandwidth and storage issue. But Chinese Band Distributor always hidden this issue to the end-user.

Thank you, IPVM.

Undisclosed #3

In reply to Franky Lam | 11/28/17 02:06am

But Chinese Band Distributor always hidden this issue to the end-user.

Like which ones?

Franky Lam

RICOH (HONG KONG) LTD
In reply to Undisclosed #3 | 11/28/17 03:08am

If you would like to know, and do use your REAL identity. I don't talk with stranger...:-P

Undisclosed #3

In reply to Franky Lam | 11/28/17 05:09am

...and do use your REAL identity. I don't talk with stranger...

No problem, I wouldn’t want you to compromise your principles, “Franky”.

Franky Lam

RICOH (HONG KONG) LTD
In reply to Undisclosed #3 | 11/28/17 06:00am

Haha, I don't know WHY, and I had the feeling I know you, "Mr. Undisclosed #3"

Undisclosed End User #4

11/29/17 02:12pm

Thank you for another great report IPVM. Question, how did you measure image quality? Did you use some type of tool or did you just manually review the video? Also what tool did you use to watch the video? The viewer inside the camera, another third party tool (ie- VMS)? These details can affect the perceived quality, hence I'm asking. Thanks!!!

Ethan Ace

IPVM | In reply to Undisclosed End User #4 | 12/04/17 04:44am

Do you mean "image quality" as in visible image quality? Or as in compression?

Compression was measured using AVInaptic, as well as Elecard StreamEye for H.265 streams.

If you mean image quality as in visible image quality, we visually compare cameras. There are software tools that measure "image quality", but I would not trust software measurements to determine what is or is not a usable image.

We view video multiple ways. Practically every cameras in this test was viewed using Exacq, VLC Player, and the camera's web interface. We don't rely on just one, but that being said, rarely are there practical differences between one VMS and another or between the web interface and a VMS, etc.

Undisclosed Integrator #5

11/18/18 02:07am

Well done as usual.