Test: H.264 I vs P Frame Impact

Avatar
Ethan Ace
•Published Oct 02, 2013 04:00 AM

****** **** *.*** ****** ********* ** only ******* **** ****** ***** ** often, ****** **** **** ******* ****** only ********* ******* ** ******* *** full ****. **** *** ****** '*' frames ******* **** *** *** *******/ **** ******, ******** ** '*', or ****************.*

****: ** *** *** *** ******** with******, ****** **** *************** ***** *********** **********.

I ***** *********

***** * ****** ******* **** **** bandwidth **** * ****** (********** ** or *** ****), **** **** ***** that ******** *** **** ** * frames **** ****** ******* ********* *************. For ********, ******* ** ****** ** I ***** **** ******, ****** ** to * ***** * *******.

** *** ***** ****, **** **** argue **** ******** * ****** *** result ** ******* ******** ******* ** can ** ****** *** *** ********* to ******** ** ********** ****** *** represent *** ***** ** ** *** changed ************* ***** *** **** * frame.

** **** ** ****** ***** *** questions:

  • *** **** ********* ******* *** *** achieve ** ******** *** * ***** interval?
  • *** **** ******* *********** *** ***** by ******** *** * ***** ********?

The ***** *********

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

  • ******** ** ***
  • **** *****
  • **** *****
  • ***** ***-****
  • ***** ******

** ***** ***** ******* ** * toy ***** *** ** ****** ********** motion, *** ****** *-***** ****** **** a ******* ** *** *** ****** to ** **** ** **** *** as *** ** *** ***** **** seconds.

***** *** ******* *** ********* **** this ****:

  • ********** *-***** ********* ******* ** ******* image ******* ***********, *** * ***** increase ** ********* ***********. ********* ** 20-35% **** ****** **** ******** *-****** from * ** * *** ******, while ********* ** **-**% **** ******** when ****** **** * ** *.
  • ********** *** ****** ** *-****** *** second ******* ** * *********** ********* in ***** ********** ****** *******, *** * **** ***** **** in *********. ****** **** *** *-***** per ****** ** *** ***** *** seconds ********* ********* ** *-**%. **-**% reductions **** **** **** ******** *-****** to *** ***** **** *******.
  • ***** ********* ********* ********* ** *-***** interval *********, *** **** *****, *** exact ****** ** **** ****** ****** across ************* *** ****** **** *** same ************. 
  • **** ******'* *-***** **** ******** ********** regardless ** *-***** ********.
  • *** ***** ***-**** *** *** **** camera ** **** **** **** *** not ******** ********* **** *** ****** of *-******. *******, *** ****** *********************, ******* *** ****** **** ********. However, ******** *** ****** ** *-****** resulted ** ********* ********** ******* ** other *******.
  • *** ***** ****** *** *** ***** for **** **** *** *-***** *** second, ****** ****** ***** **** ********.

Image ******* ******

** **** *****, ** **** *-***** interval's ****** ** ***** ******* *** to ******* ******* *************. ********* ****** *******:

  • * *-***** *** ******
  • *.* *-****** *** ******
  • * *-****** *** ******
  • * *-***** ***** * *******
  • * *-***** ***** * *******

***** ****** **** *** ******* ********* in ***** ******* ** *** ****** of *-****** ** *******, ** **** as *** ******* ***** **** **********.

Bandwidth ****** 

**** ********** *** **** ******* * frames, ********* ******** ****** *** *******, but ********, ** ***** ** **** graph:

*** ***** ***** ***** *** *** numbers *** ***** ***********:

** ********, ********** *** ****** ** I ****** ** **** ***** **** multiple **** ** * ******, ************* increased *********:

 

**** ***** ***** *** *********** ** bandwidth **** ********** **** *** *-***** per ****** ** *.* *** *. Notes **** ***** *** *** ***** for ****** *****, ** *** ******** from ***** *****. ****, *** *** notes ***** *****'* *********/*********** ***********.

P-frame *********/****

*** ****** *****, ***** *************, *********** *** ******:

  • *****, **** *** ********** ******** ** I-frames ** **** ***** (****** **** left ** *****). *-****** *** ***** as *** ****** **** *****, ***** P-frames *** *****/***.
  • ******, *** *-***** **** ** **** camera ******* ********** ********** ********** ** I-frame ********. **** *** **** ** both *** ********** *** ****** ***** test, *** ** * **** ****** scene ******* **** * ***** *****.

Bosch ***-*** *********** 

****** *** ***** ******* ** *** test, *** ***-**** *** *** ******** bandwidth **** *-***** ******** *** *********, instead ******* ************* ****** ****** * Mb/s. ******** **** ****** ** * stream ********, ** ********** **** *** camera *********** *** *** ********** *-****** by********** ************. ******* ************ *** ** follows:

  • * *-***** *** ******: ~** 
  • *.* *-****** *** ******: ~**
  • * *-****** *** ******: ~**

**** **** ************ ******** ********* **** moving **** *** *-***** *** ****** to *** ***** *** ** **** seconds, ****** ****** **.

Comments (14)
UM
Undisclosed Manufacturer #1
•Oct 02, 2013

"Decreasing the number of I-frames per second results in a significant reduction in image quality for moving objects, but a very small gain in bandwidth"

Not sure I understand why image quality would degrade depending on the interval of I-Frames ? As each P frame is encoding the difference from the last P or I frame, why does reducing the I-Frames reduce image quality ? Are you seeing this consistent across all cameras ? Are you also seeing it consistent across Variable Bitrate settings and Constant Bitrate settings ?

Avatar
Ethan Ace
•Oct 02, 2013
In reply to Undisclosed Manufacturer #1

P frames are naturally lower quality than I frames since they're using other frames as reference, as opposed to being a full capture as I frames are. It creates the artifacts you see behind moving objects, since the prediction of what is changed in each P frame (the moving object(s)) is imperfect. So in time you'll see the artifact trail grow longer and longer.

It is consistent across all cameras, as well as VBR and CBR. Using VBR, bandwidth will increase and decrease as you raise and lower I frame frequency. Using CBR, the camera should be able to use a slightly lower quantization level if you reduce I frames, but you'll still get artifacts from P frames.

UM
Undisclosed Manufacturer #1
•Oct 02, 2013
In reply to Ethan Ace

Bear with me here, just trying to get my head straight ;) So the artifacts will build up over the span of the GOP because each P frame is 'estimating' what changed from the I Frame. The 'estimation' is then encoded/compressed which in itself also introduces artifacts. ??

Avatar
Ethan Ace
•Oct 02, 2013
In reply to Undisclosed Manufacturer #1

That is correct. So if you have a car moving through a scene, for example, the encoder will see the car as a change. So it keeps the static parts of the background from the previous frame, and transmits only the changed areas (the car, as well as where the car used to be, which is now empty space). This will never be perfect, because objects are in motion. And since successive P frames reference the previous P frame for changes, it gets steadily worse until the next I frame is sent, which you can see as a "clearing" in the video.

UM
Undisclosed Manufacturer #1
•Oct 02, 2013
In reply to Ethan Ace

Got it. Never really stopped and thought about this thoroughly before. All our video is typically H264 30fps with I-Frames set at 1 sec intervals.

JH
John Honovich
•Oct 02, 2013
IPVM
In reply to Undisclosed Manufacturer #1

1 second I frame intervals is common for VMS systems, so typically one would not see a quality problem. However, some systems or users try to 'cheat' with longer I frame intervals.

Avatar
Luis Carmona
•Oct 02, 2013
Geutebruck USA • IPVMU Certified

Nice report but please try to establish early in the report what frame rate is being used when making the comparisons. After reading the report it seems 15FPS was used for these measurements?

Avatar
Ethan Ace
•Oct 02, 2013
In reply to Luis Carmona

15 FPS was used because it allowed for the most flexible configuration of higher/lower I frame intervals. I'll add a note about framerate, though, thanks.

Avatar
Luis Carmona
•Oct 02, 2013
Geutebruck USA • IPVMU Certified

Thanks. It just helps knowing all the parameters up front when reading the numbers.

SO
Stas Oskin
•Oct 03, 2013

What about testing the B-frames influence on video quality and bandwidth?

This should be interesting a well.

TF
Tiago Fioreze
•Oct 11, 2013

Interesting report, Ethan. Did you consider CPU usage in your experiment? I'm wondering how much influence (in terms of CPU usage %) increasing and reducing the I-frame interval would have.

Avatar
Ethan Ace
•Oct 11, 2013
In reply to Tiago Fioreze

We didn't initially consider it. But looking at clips now in VLC, it's marginal at best. The difference between 1 I-frame per second and 5, for example, is one percent CPU usage, at most. Reducing from 1 per second to 1 every 4 seconds decreases it by one at most. Those are the most extreme examples, and the effects are practically negligible.

MP
Michael Pratt
•Oct 14, 2013

Interesting analysis.

I often have to use low-bandwidth connections to remote cameras - T1, or approx. 1.5Mb symetrical - which is the typical business data connection in North America. xDSL is usually worse, as it's the upstream that matters for remote monitoring. And, most often these links are also used during business hours for other mission-critical applications, so you can't use all the bandwidth - assume 750Kbs is all you have. Now, try to monitor a couple/three 1MP cameras.

I did a lot of 'experimenting' with compression and frame rates, and discovered not all VMS software packages allow for user selection of the key frame refresh interval (KFRI) or (I-frame interval, or
GOV rate, or whatever the camera manufacturer calls it). In particular, Milestone's non-Enterprise solutions fix the KFRI at a minimum of 1 frame per second. So, at low frame rates - say, 1 FPS - well, that's JPEG, one full I-frame per second, and a lot of data for each image. Doing the math, it's clear that several 1MP images won't fit in 750Kbs!

Other VMS solutions (Video Insight, Exacq, for example) do indeed keep the camera settings (if available) intact in the video steam connected. I've used Axis' 'default' GOV rate of 32 (1 I-frame per 32 frames, as I understand it) at 1 FPS and got quite acceptable results, for scenes with little active motion - an occasional vehicle moving through,for example. The artifacting is all in the 'static' parts of the image, so the object of interest - the moving vehicle - is pretty well covered in the P-frame, even at 1 FPS. In fact, I never had a customer 'complain' about the artifacting, and it appears to be 'self-annealing' in subsequent P-frames. I was able to get 2-3 1MP cameras at 1 FPS each in an average of 150-175Kbs for static images, and jumping to 300-400Kbs if a lot of motion occured. Pretty incredible - usable HD video over a T1. Nighttime was typically twice the bandwidth (video noise), but other business services were not running, so I could hit the 'hard stops' of bandwidth utilization, and use the entire 1.5Mbs.

Anyway, I went to local storage for other reasons also impacted by the bandwidth (local and remote simultaneous viewing/stream generation) which generated a different set of problems for a low bandwidth connections, (and cost more) but were the best compromise in my instance.

Take-away here is make sure that the VMS is actually pulling streams at the KFRI (I-frame ratio) you think it is....

KP
Kevin Pettijohn
•Nov 25, 2013

There is a lot of good information here that could be applied when testing a camera set up. I found it interesting that the Bosch NBN-733V bandwidth did not increase with the number of I frames, but adjusted the quantization. I've never worked with a Bosch camera, but I wonder if there are other cameras that exhibit this same behavior.