X264 RC params

[rubypin]

hello, i am not know quite clearly about the meaning of several rc params:

float blurred_complexity;

typedef struct
{
double coeff;
double count;
double decay;
} predictor_t;

/* ABR stuff */
int last_satd;
double last_rceq;
double cplxr_sum;
double expected_bits_sum;
double wanted_bits_window;
double cbr_decay;
double short_term_cplxsum;
double short_term_cplxcount;

/* 2pass stuff */
int last_non_b_pict_type;
double accum_p_qp;
double accum_p_norm;
double last_accum_p_norm;
double i_cplx_sum[5];
double p_cplx_sum[5];
double mv_bits_sum[5];

is there anyone who can help me?

[rubypin]

and:
since qscale can be calculated from qp, why set it? what's its meaning?

[rubypin]

and:
i_itex_bits;
i_ptex_bits;
i_misc_bits;
what are these stand for?

[Audionut]

Another that doesn't use the edit button.

You have 3 posts within 5 mins of each other.
Use the edit button instead.

[rubypin]

Another that doesn't use the edit button.

so what's the matter?

[unmei]

it is a possible interpretation of rules 11+12 that the use of the edit button is preferred over posting several consecutive posts (well unless your posts are so big that you cannot put everything in one due to the character limit, i guess ;))

but back on topic, i never looked at the x264 source, but what you list here does really not look like the caller had to set that up but rather like the algorithm will use these stuct fields for private temporary storage. But if i got you wrong, and you want to know how it works inside, i guess the best bet is to actually look at the relevant code ..i.e what values the fields get assigned.
Also
since qscale can be calculated from qp, why set it? what's its meaning?
In order not to recompute it everytime it is used, probably. Recalculating stuff too often is a certain way to sluggish execution :)

[akupenguin]

What you list here does really not look like the caller had to set that up but rather like the algorithm will use these stuct fields for private temporary storage.
Correct. Those are variables, not parameters. Note that the whole struct is defined only in ratecontrol.c, and thus is an opaque blob from the point of view of the caller. The parameters are in x264_param_t.rc.

[rubypin]

yes, i am sorry, i was wrong.
but the algorithm is difficult for me, i cann't make clear what is it doing. is there any information can help to read it?
especially 2pass.

[rubypin]

besides,i have read the artical "x264_rc_method.txt", but still confused with the algorithm.

[rubypin]

another problem:
in the program, we can also see:
if( i_force_qp ).......................each frame use the same qp
else if( rc->b_abr ).................1pass abr
else if( rc->b_2pass )..............2pass
else /* CQP */ ......................qp depand on the type of frame

am i right?
so where is the 1pass cbr?

[rubypin]

In order not to recompute it everytime it is used, probably. Recalculating stuff too often is a certain way to sluggish execution :)[/QUOTE]

in the programe it write:
/* Terminology:
* qp = h.264's quantizer
* qscale = linearized quantizer = Lagrange multiplier
*/

since qscale is converted frome qp, and x264 do not use the lagrangian arithmetic, what's the mean by "qscale = linearized quantizer = Lagrange multiplier"?

[bond]

rubypin, use the edit button please before writing a new post