[MEncoder-users] CRF vs. 2-pass (was: Tuning hqdn3d)

[vmrsss]

On 20 May 2009, at 05:11, Andrew Berg wrote:
> How exactly does x264 use the information gathered in the first pass  
> to
> distribute bits in a manner that is more optimal than CRF? As far as I
> can tell, that information is used for little, if anything at all,  
> more
> than to ensure an average bitrate.

well said, it's enough to look at the code for that. Or even simpler,  
read a short document by Loren Merritt entitled "A qualitative  
overview of x264's ratecontrol methods"

This is a relevant fragment of it:

>     2pass:
> Given some data about each frame of a 1st pass (e.g. generated by  
> 1pass ABR, below), we try to choose QPs to maximize quality while  
> matching a specified total size. This is separated into 3 parts:
> (1) Before starting the 2nd pass, select the relative number of bits  
> to allocate between frames. This pays no attention to the total size  
> of the encode. The default formula, empirically selected to balance  
> between the 1st 2 theoretical points, is "complexity ** 0.6", where  
> complexity is defined to be the bit size of the frame at a constant  
> QP (estimated from the 1st pass).
> (2) Scale the results of (1) to fill the requested total size.  
> Optional: Impose VBV limitations. Due to nonlinearities in the frame  
> size predictor and in VBV, this is an iterative process.
> (3) Now start encoding. After each frame, update future QPs to  
> compensate for mispredictions in size. If the 2nd pass is  
> consistently off from the predicted size (usually because we use  
> slower compression options than the 1st pass), then we multiply all  
> future frames' qscales by the reciprocal of the error. Additionally,  
> there is a short-term compensation to prevent us from deviating too  
> far from the desired size near the beginning (when we don't have  
> much data for the global compensation) and near the end (when global  
> doesn't have time to react).

[snip]

>     1pass, average bitrate:
> The goal is the same as in 2pass, but here we don't have the benefit  
> of a previous encode, so all ratecontrol must be done during the  
> encode.
> (1) This is the same as in 2pass, except that instead of estimating  
> complexity from a previous encode, we run a fast motion estimation  
> algo over a half-resolution version of the frame, and use the SATD  
> residuals (these are also used in the decision between P- and B- 
> frames).

[snip]

>     1pass, constant ratefactor:
> (1) Same as ABR.
> (2) The scaling factor is a constant based on the --crf argument.
> (3) No overflow compensation is done.
>