[x264-devel] x264 rate control

Jason Garrett-Glaser jason at x264.com
Tue Jan 29 19:35:41 CET 2013


On Tue, Jan 29, 2013 at 7:35 AM, eloise vidal <eloise.vidal at gmail.com> wrote:
> I am working on CBR streaming applications and I compare x264 to Mainconcept
> in terme of quality (PSNR, SSIM), performance (frame encoded per second) and
> rate control accuracy.
>
> I read the "Video Codec Comparison" of CS MSU Graphics&Media Lab, Video
> Group. This comparison shows that x264 is the best codec in terme of SSIM,
> but I cannot find the same results because of the rate control.
>
> I use sequences of 200 frames for my tests. Here is an exemple of the
> command line I use for HD sequence :
> x264 --input-res 1920x1080 --fps 25 --bitrate 8000 --vbv-maxrate 8000
> --vbv-bufsize 3000 --profile high -o Output.h264 Input.yuv
>
> Mainconcept uses a buffer size of 3Mbit for HD sequence

Erm, the encoder doesn't use a specific buffer size; you set the
buffer size based on your use-case.

> With this buffer size, x264 does not succeed in achieving 8Mb/s but 6MB/s.
> To achieve 8Mb/s, I have to choose a bigger buffer of 35Mbit, but firstly I
> add more than 4sec of latency!

On a very short clip, you may get well over or under the target
bitrate because the buffer state at the end of the video may be
different than the buffer state at the start.

Additionally, that small of a VBV buffer doesn't match any real-world
application that I know of.  Even broadcast is usually about 0.7-1
second at the least.

> And secondly, the rate control needs a lot of
> frames to be stable, a small number of bits are allocated to the frames at
> the begining of the sequence

How many threads are you using?  If you're using significantly more
threads than the VBV buffer fits frames, x264's compression will
suffer dramatically.

Jason


More information about the x264-devel mailing list