[x264-devel] x264 rate control

[eloise vidal]

Thank you for this quick response,

I don't indicate the number of thread, but I checked the value of the
parameter "i_thread_frames", it is automatically set to 24.

So I made two tests (x264 --input-res 1920x1080 --fps 25 --bitrate 8000 --
vbv-maxrate 8000 ...) :

1. I increase the buffer size (initially 3M=9~10frames) to 8M (25 frames)
vbv_bufsize = 3M --> achieved bitrate =  6125.30
vbv_bufsize = 8M --> achieved bitrate =  6904.92.

2. I decrease the number of thread (initially 24) to 8, with bufsize 3M :
i_thread_frames = 24 --> achieved bitrate =  6125.30, fps = 22.04
i_thread_frames = 8 --> achieved bitrate =  7166.56, fps = 10.99
--> Actually, if I decrease the number of threads, the achieved bitrate is
better but of course, the number of frames coded per second, decreases and
that is not a solution for a real time application.

That is very suprising for me, is that the rate control allocates very few
bits to the first frames, and it spends all the sequence (200 frames) to
increase the number of bit per frame to reach the target bitrate.
If the target bitrate is specified, why the rate control allocates too few
bit at the begining of the sequence? I checked the value of the parameter "
wanted_bits_window" and it is bitrate/fps as expected.

The only solution I found is to use VBR (ABR) : x264 --input-res 1920x1080
--fps 25 --bitrate 8000 --vbv-maxrate 24000 vbv_bufsize 3000
In this case, the rate control allocates the good number of bits per
frame right
from the start of the sequence and it succeeds in achieving the target
bitrate, but I cannot be sure that the bitrate (bit/sec) is always below 8M
...



2013/1/29 Jason Garrett-Glaser <jason at x264.com>

> 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
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20130130/e81abdcc/attachment-0001.html>