2pass ratecontrol in x264

[chen]

in the 2pass part of the function rate_estimate_qscale( ) stands the following piece of code:

if( h->fenc->i_frame > 30 )
{
/* Adjust quant based on the difference between
* achieved and expected bitrate so far */
double time = (double)h->fenc->i_frame / rcc->num_entries;
double w = x264_clip3f( time*100, 0.0, 1.0 );
q *= pow( (double)total_bits / rcc->expected_bits_sum, w );
}

We see that during the encoding of the first 1% of the frames, w is changing frame after frame. After that, w keeps being a constant = 1. I would like to know why the processing of the first 1% frames is quite different from that of all the following.

[Nic]

You're probably better off asking the x264 mailing list to get a complete answer (x264-devel@videolan.org).

(I'm guessing it is because it is more tricky to ascertain a bitrate (which is bits/sec) before a complete second of time has passed, but I could be completely wrong, I haven't looked at the code)

OT:
Wasn't it Richard Porson that said "Life is too short to learn German", rather than Mark Twain?

[akupenguin]

The purpose of that code snippet is to compensate for global trends if the 2nd pass has a significantly different compressability than the 1st (e.g. if you used fast 1st pass).
At the beginning, we don't yet have a good estimate of compressability. As the estimate improves, we allow stronger compensation. Maybe 1% isn't the best range, but like most of the magic numbers in ratecontrol.c and slicetype_decision.c, it has not been thoroughly tuned.

[chen]

In get_diff_limited_q( ) in the ratecontrol.c is the following piece of code written:
......
else if( h->param.rc.f_ip_factor < 0 )
q = iq / ip_factor;
......

What does it mean if an ip_factor is negative? i am a bit confused.

[akupenguin]

That's left over from libavcodec, which has a mode where I-frames' QPs are a function of the frame's own complexity instead of locked to the following P-frames. In my experience that's not as good as the current method, but I didn't see any reason to remove the code.

[chen]

@akupenguin

else if(rcc->b_2pass)
{
double min2 = log(lmin);
double max2 = log(lmax);
q = (log(q) - min2)/(max2-min2) - 0.5;
q = 1.0/(1.0 + exp(-4*q));
q = q*(max2-min2) + min2;
return exp(q);
}

The function of the above piece of code is obvious: map [-inf, inf] into the range of [lmin, lmax]. This mapping function has quite a good continuity, but only the value q=(lmin+lmax)/2 is kept, others are more or less distorted. In comparison, the function clip(q, lmin, lmax) keeps all the values between lmin and lmax, although it resets the values beyond the range simply to lmin or lmax, which introduces discontinuity.

My question is why we apply different clipping scheme to 1pass and 2pass. If the piece of code i quoted above is more applicable to 2paa than the simple function clip(q, lmin, lmax), why is it only used for VBV constraints?

[akupenguin]

Also leftover from libavcodec. I haven't experimented with different clipping.

[chen]

In 2pass ratecontrol, there is one step that fixes the qscale of I- and B-frames relative to P_frames. Trace back to 1pass_abr, it is quite similar that the qscale of I- and B-frames are derived from P-frames.

I wonder why we manage it in this way. Is there some kind of principle in nature, or is it just to simplify the algorithm?