Bug 82983

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.