rate control problem in X264

[dy_dragon]

I want to get a bitstream with smooth bitrate, so I used the ABR method of x264. However, even the total bitrate is near the target bitrate, the rate curve fluctuates very strong.
Is x264 not focus on rate control?

[Dark Shikari]

ABR is not CBR. Of course it fluctuates a lot.

[NaturalThoughts]

Please use 2pass instead of 1pass for better rate control.

[wyti]

if you really want low fluctuation in your bitrate, lower --qcomp (0 = CBR 1=CQP) option.
note that thoses fluctuations are here to give you better quality output, and you will get worse quality with a low --qcomp.

[dy_dragon]

This curve was produced by --qcomp 0.
Because of the demand of real transcoding, I can't use 2pass rate control. However, many h.264 encoder including Mainconcept, JM, can do better rate control.
From the ratecontrol.c, I guess the target of x264 rate control is to make the average rate near the target rate, but not focus on the smoothness of instant rate.

[Dark Shikari]

This curve was produced by --qcomp 0.
Because of the demand of real transcoding, I can't use 2pass rate control.Never, ever adjust qcomp for any reason unless you absolutely know exactly what you are doing! It will not produce the results you expect.

In fact, I have never seen "qcomp=0" used correctly in my entire history of working on x264. Don't mess with it.However, many h.264 encoder including Mainconcept, JM, can do better rate control.
From the ratecontrol.c, I guess the target of x264 rate control is to make the average rate near the target rate, but not focus on the smoothness of instant rate.JM's ratecontrol is an absolute joke.

I would say x264 ratecontrol is better than the vast majority of H.264 encoders, but it will not give good results if you screw with its internal parameters in arbitrary ways for no good reason.

[NaturalThoughts]

if you really want low fluctuation in your bitrate, lower --qcomp (0 = CBR 1=CQP) option.
note that thoses fluctuations are here to give you better quality output, and you will get worse quality with a low --qcomp.

I think dy_dragon played with 'qcomp' becoz of this........

Ok then what will be the best parameter setting for 1pass ,No B-frame and ABR..???

[dy_dragon]

I would say x264 ratecontrol is better than the vast majority of H.264 encoders, but it will not give good results if you screw with its internal parameters in arbitrary ways for no good reason.
Here is the comparison of rate control result between Mainconcept and X264. We ca see the rate curve of X264 fluctuate very high.
Theoretically, a good rate control method should make the rate curve smooth, so the vbv buffer will not overflow or underflow. Of course, the available bits should be allocated to each frame according to their texture and motion degree, to maximum the overall quality.
From the comparison, only the average bitrate is near the target bitrate. The smoothness is not acheived, and the video quality is fluctuate too.
BTW, I'm not a gunman for Mainconcept. I just want to discuss the rate control problem in X264.

[Dark Shikari]

Here is the comparison of rate control result between Mainconcept and X264. We ca see the rate curve of X264 fluctuate very high.
Theoretically, a good rate control method should make the rate curve smooth, so the vbv buffer will not overflow or underflow.x264 will warn you if it violates its VBV buffer parameters. If it doesn't warn you, it didn't violate the parameters.

Also, stop using attachments; they have to be approved, so there is a long delay before I can see what you're talking about. Host on an image site like tinypic.

Additionally, you still haven't posted the settings you are using for your encode. As we are not psychic, it is rather difficult to help you with problems you are experiencing if we don't even know what you're doing.

[dy_dragon]

<a href="http://tinypic.com" target="_blank"><img src="http://i29.tinypic.com/2my5fuu.jpg" border="0" alt="Image and video hosting by TinyPic"></a>
<a href="http://tinypic.com" target="_blank"><img src="http://i30.tinypic.com/2zgb4lz.jpg" border="0" alt="Image and video hosting by TinyPic"></a>

The parameters I used are:

x264_param_default(&_param);
_param.i_frame_reference = 3 _param.i_keyint_max = 125;
_param.i_keyint_min = 25;
_param.b_cabac = 1;
_param.i_threads = 3;
_param.b_aud = 1;
_param.i_bframe_adaptive = 0 _param.i_bframe = 3;
_param.i_bframe_bias = 30;
_param.i_log_level = X264_LOG_NONE;
_param.rc.i_rc_method = X264_RC_ABR _param.rc.i_bitrate = 1400;
_param.rc.i_vbv_buffer_size = _param.rc.i_bitrate ;
_param.rc.i_vbv_max_bitrate = _param.rc.i_bitrate * 1.1;
_param.rc.f_vbv_buffer_init = 0.7;

_param.rc.f_rate_tolerance = 0.01;
_param.rc.i_qp_constant = 20;
_param.rc.f_ip_factor = 1.1;
_param.rc.f_pb_factor = 1.1;
_param.rc.f_qcompress = 0.0;//0.4
_param.rc.f_qblur = 0.5;
_param.rc.f_complexity_blur = 20;
_param.rc.i_aq_mode = X264_AQ_NONE;
_param.rc.f_aq_strength = 0.5;

_param.analyse.i_me_method = X264_ME_UMH;
_param.analyse.i_subpel_refine = 7;
_param.analyse.i_me_range = 16;
_param.analyse.b_psnr = 0;
_param.analyse.b_ssim = 0;
_param.analyse.i_noise_reduction = 2;
_param.analyse.inter = X264_ANALYSE_I4x4 | X264_ANALYSE_I8x8
| X264_ANALYSE_PSUB16x16 | X264_ANALYSE_PSUB8x8 | X264_ANALYSE_BSUB16x16;

[dy_dragon]

http://i30.tinypic.com/2zgb4lz.jpghttp://i29.tinypic.com/2my5fuu.jpg

[Dark Shikari]

_param.rc.f_rate_tolerance = 0.01;
_param.rc.f_ip_factor = 1.1;
_param.rc.f_pb_factor = 1.1;
_param.rc.f_qcompress = 0.0;//0.4
_param.rc.i_aq_mode = X264_AQ_NONE;
_param.rc.f_aq_strength = 0.5;So, how many times will I have to tell you about not touching parameters that you don't understand? ;)

If you don't know what they do, leave them on defaults. You will get much better results. Also, make sure you have the latest x264, which uses VBV lookahead for improved ratecontrol in VBV mode.

[me7]

I feel like there is a misunderstanding about what ABR should and should not do.
The whole purpose of ABR is to NOT HAVE a stady bitrate. The bitrate of an ABR encode is supposed to FLUCTUATE AS MUCH AS POSSIBLE within the VBV requirements in order to maximize the image quality.

Why do you need a bitstream with smooth bitrate?

[dy_dragon]

So, how many times will I have to tell you about not touching parameters that you don't understand? ;)

If you don't know what they do, leave them on defaults. You will get much better results. Also, make sure you have the latest x264, which uses VBV lookahead for improved ratecontrol in VBV mode.

The x264 version I used is x264-snapshot-20090604-2245.

To the parameters, I think:
f_rate_tolerance : the degree of rate fluctuation we can tolerance. It is used in computation of "abr_buffer", to get the "overflow", which means the distance between actual and target bitrate, and used this overflow to adjust "q" slightly.
The f_ip_factor and f_pb_factor means the qp offset between I/P,or P/B. This offset will be added to or subbed from the aforesaid "q".
i_aq_mode will affect the qp computation in MBs in a frame. the aforesaid "q" is the preset average q in one frame. Each MB in this frame will compute its own qp furthermore, according to its AC energe. I tuned is off, because I want a single qp in one frame.
f_qcompress is used in computation of cplxr_sum. The rate control method in x264 is a simple empirical method. Theoretically, the bitrate is decide by MAD and QSetp. Thus, the x264 used the actual bits and average qstep to get a factor, and used this factor to estimate the qstep of next frame.
Am i right?
Additionly, the bits used to get the factor does not including the NALU_OVERHEAD. And the method does not use a slide window to make the rate changing smoothly.

[Dark Shikari]

The x264 version I used is x264-snapshot-20090604-2245.This is quite outdated, and does not have VBV lookahead.
f_rate_tolerance : the degree of rate fluctuation we can tolerance. It is used in computation of "abr_buffer", to get the "overflow", which means the distance between actual and target bitrate, and used this overflow to adjust "q" slightly.Correct. It is not important for VBV accuracy, only for average overall bitrate. In CBR, for example, it is basically meaningless.f_qcompress is used in computation of cplxr_sum. The rate control method in x264 is a simple empirical method. Theoretically, the bitrate is decide by MAD and QSetp. Thus, the x264 used the actual bits and average qstep to get a factor, and used this factor to estimate the qstep of next frame.

Am i right?Not exactly. Qcomp is used to weight frame quantizer relative to residual complexity, which is measured via lookahead with SATD. If you want to turn off Qcomp, set it to 1, not 0. Note that the behavior of qcomp has changed by default in the latest x264 (with MB-tree ratecontrol).

By the way, setting qcomp to 0 when using CBR creates exactly the kind of "waving" present in your screenshot. Don't do it.And the method does not use a slide window to make the rate changing smoothly.cplxblur does work over a sliding window for exactly that purpose.Additionly, the bits used to get the factor does not including the NALU_OVERHEAD.That kind of tiny difference is practically meaningless when it comes to ABR targeting. It also makes the assumption that the output container will have that overhead, which it may not, as not all containers use startcodes.

Now, you still haven't told us what commandline you are using. In fact, I'm still not sure if you're using CBR or ABR. Your graphs suggest CBR, but at this point I'm just completely guessing.

Furthermore, when reporting a bug, it is generally good form to provide all the information necessary to replicate it, which means not only the commandline, but also an input file.

[dy_dragon]

Now, you still haven't told us what commandline you are using. In fact, I'm still not sure if you're using CBR or ABR. Your graphs suggest CBR, but at this point I'm just completely guessing.

Furthermore, when reporting a bug, it is generally good form to provide all the information necessary to replicate it, which means not only the commandline, but also an input file.

Sorry. I does not used to the commandline, so I directly changed the param in main function. ;) But the parameters I used are posted above.

The size of input file is more than 1G. Sorry again.:p

[Dark Shikari]

Sorry. I does not used to the commandline, so I directly changed the param in main function. ;) But the parameters I used are posted above.You didn't set any other parameters, like perhaps a bitrate? That list seems incomplete.The size of input file is more than 1G. Sorry again.:pThen upload a small section which produces the problem.

[dy_dragon]

Fist, I get the default parameters. Then I change some option.
To the input file, I test several materials, the result is as the same.

x264param_default(&param);
param.i_frame_reference = 3 ;
param.i_keyint_max = 125;
param.i_keyint_min = 25;
param.b_cabac = 1;
param.i_threads = 3;
param.b_aud = 1;
param.i_bframe_adaptive = 0 ;
param.i_bframe = 3;
param.i_bframe_bias = 30;
param.i_log_level = X264_LOG_NONE;
param.rc.i_rc_method = X264_RC_ABR ;
param.rc.i_bitrate = 1400;
param.rc.i_vbv_buffer_size = param.rc.i_bitrate ;
param.rc.i_vbv_max_bitrate = param.rc.i_bitrate * 1.1;
param.rc.f_vbv_buffer_init = 0.7;

param.rc.f_rate_tolerance = 0.01;
param.rc.i_qp_constant = 20;
param.rc.f_ip_factor = 1.1;
param.rc.f_pb_factor = 1.1;
param.rc.f_qcompress = 0.0;//0.4
param.rc.f_qblur = 0.5;
param.rc.f_complexity_blur = 20;
param.rc.i_aq_mode = X264_AQ_NONE;
param.rc.f_aq_strength = 0.5;

param.analyse.i_me_method = X264_ME_UMH;
param.analyse.i_subpel_refine = 7;
param.analyse.i_me_range = 16;
param.analyse.b_psnr = 0;
param.analyse.b_ssim = 0;
param.analyse.i_noise_reduction = 2;
param.analyse.inter = X264_ANALYSE_I4x4 | X264_ANALYSE_I8x8
| X264_ANALYSE_PSUB16x16 | X264_ANALYSE_PSUB8x8 | X264_ANALYSE_BSUB16x16;

[Dark Shikari]

I've told you roughly half a dozen times to stop setting qcomp to 0.0, and yet you keep setting qcomp to 0.0.

I'm not going to bother with this anymore if you cannot follow basic instructions.

[dy_dragon]

OK, don't be angry. I'll try it again according to your instruction.

[dy_dragon]

http://i27.tinypic.com/qy8ei9.jpg
I changed the f_qcompress to 0.6, and some other parameters, but the result seems very similar. The parameters are:
_param.i_width=720;
_param.i_height=576;
_param.i_fps_num=25;
_param.i_fps_den=1;
_param.i_frame_reference=3;
_param.i_keyint_max=125;
_param.i_keyint_min=25;
_param.b_cabac=1;
_param.i_threads=3;
_param.b_aud=1;
_param.i_bframe_adaptive=0;
_param.i_bframe=3;
_param.i_bframe_bias=0;
_param.i_log_level=X264_LOG_NONE;
_param.rc.i_rc_method=X264_RC_ABR;
_param.rc.i_bitrate=1400;
_param.rc.i_vbv_buffer_size=_param.rc.i_bitrate;
_param.rc.i_vbv_max_bitrate=_param.rc.i_bitrate*1.1;
_param.rc.f_vbv_buffer_init=0.9;
_param.rc.f_rate_tolerance=0.01;
_param.rc.i_qp_constant=20;
_param.rc.f_ip_factor=1.4;
_param.rc.f_pb_factor=1.3;
_param.rc.f_qcompress=0.6;
_param.rc.f_qblur=0.5;
_param.rc.f_complexity_blur=20;
_param.rc.i_aq_mode=X264_AQ_NONE;
_param.rc.f_aq_strength=0.5;
_param.rc.i_qp_max=40;
_param.rc.i_qp_min=10;
_param.analyse.i_me_method=X264_ME_UMH;
_param.analyse.i_subpel_refine=7;
_param.analyse.i_me_range=16;
_param.analyse.b_psnr=0;
_param.analyse.b_ssim=0;
_param.analyse.i_noise_reduction=2;
_param.analyse.inter=X264_ANALYSE_I4x4|X264_ANALYSE_I8x8|X264_ANALYSE_PSUB16x16|X264_ANALYSE_PSUB8x8|X264_ANALYSE_BSUB16x16;

[LoRd_MuldeR]

What exactly do you expect ???

Even with VBV enabled (no VBV violations) and a constant VBV data rate, the actual video bitrate may still be variable.
That's because only the data rate that enters the VBV buffer is constant (e.g. limited by network bandwidth or disc read speed). Still the video bitrate that leaves the buffer can fluctuate!
In other words: The buffer can cope with short bitrate spikes. And these spikes may exceed the VBV bitrate. This is perfectly valid under VBV. And it's good the way it is...

[dy_dragon]

I've post the result of Mainconcept encoder. The rate curve of MC is more smooth than x264. In real time application, the rate curve can't fluctuate high. otherwise, the stream data will be discard when it reach the receiver after its decoding time.

[LoRd_MuldeR]

I've post the result of Mainconcept encoder. The rate curve of MC is more smooth than x264. In real time application, the rate curve can't fluctuate high. otherwise, the stream data will be discard when it reach the receiver after its decoding time.

As I already explained, it's perfectly valid that the video bitrate fluctuates! In fact we want the bitrate to fluctuate as much as needed for "optimal" video quality ;)

For "real time" applications you neither need nor want a constant (or "almost constant") video bitrate. What you want is a limited maximum data rate!

VBV exists to ensure that the bandwidth limitations as well as the buffer limitations are NOT violated. That's what VBV in x264 does. And in case x264 violates VBV, it will report that!

It seems you have a rather bizzare idea of what VBV does. It doesn't limit the bitrate fluctuations. No, it allows the maximum bitrate fluctuations that don't violate VBV.

So unless x264 prints out any VBV errors, everything is perfect and there is no reason for complaint...

[Dark Shikari]

Lord_Mulder, please don't post about what you have no idea about.

dy_dragon, please post samples of the input and output stream. I apologize for the more... overly vocal users on these forums, though my patience is running thin as well (it's impossible to try to debug a problem without having input or output streams).

Also, dy_dragon, if you drop by x264 IRC on Freenode (#x264), we can get this dealt with much quicker.

[dy_dragon]

In fact we want the bitrate to fluctuate as much as needed for "optimal" video quality...
You are right. We used VBV to assure the buffer will not underflow or overflow while get the optimal video quality, by allocating available bits flexible between continuous frames. However, as we can see from the result, the rate curve fluctuate periodly, like a sine wave. It does not like a result that allocating more bits to important frames. Instead, it like that the real bits is not near the target bits, and adjust this difference in the following frame by increase or decrease the target bits.

[dy_dragon]

please post samples of the input and output stream.
Dark Shikari, where should I post my input and output stream?

[Dark Shikari]

Dark Shikari, where should I post my input and output stream?Mediafire is a good place to upload files (up to 100MB).

As I said earlier, just drop by IRC if you want this done quicker.

[LoRd_MuldeR]

However, as we can see from the result, the rate curve fluctuate periodly

Well, one would expect the bitrate to fluctuate periodically in a way, because I-Frames appear periodically too and they are "bigger" than the surrounding frames (same between P- and B-Frames).

It does not like a result that allocating more bits to important frames. Instead, it like that the real bits is not near the target bits, and adjust this difference in the following frame by increase or decrease the target bits.

Ah, that sounds more like a problem. I see...

[nurbs]

_param.rc.f_rate_tolerance=0.01;
Have you tried using the default value (1) instead?

[detmek]

Guys on HA like to say that, if you want to measure audio quality, don't look a curve in Wave Editor, just listen the music.
@dy_dragon
Don't measure quality by looking bitrate curve. If you don't like visual quality, x264 gives you an error or it doesn't work with your player/application, upload problematic part. Otherwise, you don't have a problem.