Bug 82983 - [h264encode][IVB] Encoding H.264 content Using CBR rate control does not result in "constant" bitrate
Summary: [h264encode][IVB] Encoding H.264 content Using CBR rate control does not resu...
Status: CLOSED WONTFIX
Alias: None
Product: libva
Classification: Unclassified
Component: intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium blocker
Assignee: Pengfei
QA Contact: Sean V Kelley
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-23 05:49 UTC by Chris Healy
Modified: 2016-11-03 21:10 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Here's a picture showing some of the bitrate variance I've gotten out of the encoder. (51.38 KB, image/png)
2014-08-24 14:43 UTC, Chris Healy
Details

Description Chris Healy 2014-08-23 05:49:40 UTC
Encoding H.264 video using the CBR algorithm on Ivy Bridge Intel HW does not result in a constant bitrate.  (Likely, this is true for other Intel Chipsets too.)  The rate control algorithm appears to average the bitrate over a 20 second window resulting in large spikes in the instentaneous (one second) bitrate if the video complexity moves from low complexity to high complexity.  The attached video demonstrates such an encode scenario.  At time 1:09, the complexity drops down very low and the bitrate follows.  At time 1:24, the complexity goes way up due to the cross fade which results in a big spike in bitrate.

From what I have gathered, when the complexity drops down, the rate control algorithm, increases the QP to 1 in an attempt to maintain the "constant" bitrate.  Then, when the complexity goes way up due to the cross fade, the bitrate goes through the roof as the QP is still set to 1.  The rate control algorithm eventually increases the QP value, but it does not happen fast enough to keep the bitrate at a reasonable level.

When I target 4Mbps, I still end up with a bitrate of <1Mbps when there is a static image and a bitrate spike up to ~17Mbps during the cross fade after the static image.

As I understand it, one of the main purposes of CBR is to deal with streaming and a constrained amount of bandwidth available to transmit over.  (That's the application I'm working with.)

The rate control algorithm for doing CBR is in src/gen6_mfc_common.c:intel_mfc_brc_postpack.  I'm not sure where it came from.  It would be good to know what the requirements were that drove the implementation.

I've attached a test file that is in MP4 format.  It can be converted to YUV format using the following ffmpeg or avconv command:  "avconv -i capture.mp4 capture.yuv"  This will result in a 3.4GB YUV file that can be fed into "avenc" from "libva/test/encode".  The width is 1248 and the height is 704.
Comment 1 Chris Healy 2014-08-23 06:09:24 UTC
The attachement was too large, so I've made it available via dropbox.  Here's a link to the MP4 file.  It's ~40MB.

https://dl.dropboxusercontent.com/u/1010693/capture.mp4

If you right click on the video, you can download it by clicking on "Save video as..."
Comment 2 Chris Healy 2014-08-24 14:43:32 UTC
Created attachment 105200 [details]
Here's a picture showing some of the bitrate variance I've gotten out of the encoder.
Comment 3 janardana 2015-09-27 05:30:20 UTC
This issue is still present in gstreamr-vaapi-0.6 and gstreamr-vaapi-master. 

It is very easy to reproduce if you try to encode for 1080p/30fps/8mbps rtsp video source. 

One easy way can be to simulate rtsp source using vlc and try to encode it using gstreamer-vaapi.
Comment 4 haihao 2015-11-26 05:21:11 UTC
We will try to improve the quality for encoding.  IVB is legacy platform, so drop the priority to medium.
Comment 5 Sean V Kelley 2016-11-03 21:10:16 UTC
Current limitations on IVB support.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.