[MPlayer-dev-eng] [PATCH] "turbo" mode

[Loren Merritt]

On Sun, 19 Sep 2004, Guillaume POIRIER wrote:
> Le ven 17/09/2004 à 18:37, Loren Merritt a écrit :
>> On Fri, 17 Sep 2004, Guillaume POIRIER wrote:
>>> Now, this analysis is only based on quants.
>>
>> Quants are a pretty coarse measure. The actual parameter output by
>> rate control is lambda (lagrange multiplier), which is continuous. so you
>> might have a frame that wanted quant=1.6 (rounded to 2) on one pass, and
>> 2.4 (rounded to 2) on the other. But you can't see the actual lambda
>> unless you modify mencoder to output another divx2pass.log on the second
>> pass (attached).
>
> First, I'd like to thank you for the enlightenment.
> Then, just for the sake of curiosity, I skimmed though the paper
> "Lagrange multiplier selection in hybrid video coder control"... I don't
> have a strong knowledge in video encoding, but it allowed me to
> - first understand what those damn Lagrange multiplier that I headed
> about on several places do. If I understood correctly, the constrain in
> video encoding is the target size (or the average bit-rate), so Lagrange
> multipliers seem to be a good was to optimize the usage of bits...
> Right?,

The simplest explanation of Lagrange multipliers I can think of, is:
1/lambda is the number of bits you're willing to spend to gain 1 unit of
quality.
So the encoder spends bits where they're most useful, rather than 
trying to maintain constant quality. 
(This happens even when encoding at constant quantizer, because not all 
size vs quality decisions involve quantizers: mbd=2, trellis, cbp, *cmp=6, 
and maybe some others are also affected.)

> - then, it allowed me to understand why 3-pass is an interesting idea to
> dig.... But I'm wondering... Wouldn't it be nice, instead of having a
> 1st pass that outputs quantizers, to have it output "Lagrange
> multipliers" too? Please forgive me if that sound like a dumb question,
> I'm just trying to understand how it works.

1) See those entries in divx2pass.log that look like "q:236"?
Those are lagrange multipliers, and 236 is the lambda used then you 
select vqscale=2. (That space used to contain quantizers, which is why 
it's labelled "q" and why countquant.pl is obsolete.)

2) 3-pass doesn't really have anything to do with Lagrange multipliers, 
other than that they allow controlling quality/bitrate in a more 
continuous manner than the integer quants.
3-pass doesn't even change the target distribution of quality/bits.
What it does do, is it improves the accuracy of the function that predicts 
the size of a given frame at a given lambda. In the first pass, you get 
a measure of the complexity of each frame. But that measure doesn't scale 
perfectly when the target size is very different from the initial size. 
No matter whether you use vqscale or cbr for the first pass, many frames 
will have a very different target quality on the second pass, so this adds 
some inaccuracy to the rate control. (It can adjust to maintain your 
desired average bitrate, but the distribution of bits will still be off.)
But now the 2nd pass is very close to the desired distribution, so the 
size predictor will be much better, so the 3rd pass will be closer yet.

You could run more than 3 passes, but it makes absolutely no quality 
difference in my tests, either global or per-frame.
(In contrast to DivX5, which needs about 4 passes for its rate 
control to converge, sometimes more.)

>> and an acceptable difference might be the same
>> order of difference as between a 2 pass and a 3 pass encode,
>> whatever number that happens to be.
>
> Ok... I haven't investigate 3-pass mode, but when I have more time,
> I plan to experience with it.
> Am I right to assume that, from a user point of view, it just works like
> a 2-pass encode? (you just have to run 3 times the encode, incrementing
> vpass each time, and adding more cpu-hungry options?)

With my patch, it's actually:
vpass=1 writes the stats file,
vpass=2 reads the stats file and bases ratecontrol decisions on it,
vpass=3 does both (First read the stats then overwrite them. 
And you should backup divx2pass.log before doing this if there's any 
possibility that you'll have to cancel mencoder).

So do the first pass with vpass=1, all subsequent passes with vpass=3.
You can't just run a 3rd pass after a normal 2nd pass, because the 2nd 
pass didn't save the required data.

And yes, the principle of turbo still applies.
My favourite settings are something like:

vpass=1,vqscale=2,mbd=2,trell,v4mv,precmp=0,cmp=0,subcmp=2,dia=-1,last_pred=1,vmax_b_frames=1
vpass=3,vbitrate=1200,mbd=2,trell,v4mv,precmp=0,cmp=2,subcmp=6,preme=2,dia=-1,predia=4,last_pred=3,mv0,cbp,qprd,lmin=1,lmax=4,vqmin=1,vqmax=6,vratetol=100000,vqcomp=0.6
vpass=3,vbitrate=1200,mbd=2,trell,v4mv,precmp=0,cmp=2,subcmp=6,preme=2,dia=3,predia=4,last_pred=3,mv0,cbp,qprd,lmin=1,lmax=4,vqmin=1,vqmax=6,vratetol=100000,vqcomp=0.6,qns=3

(Yes, I allow quant 1. It really does make a visible difference in 
well denoised, low motion anime scenes.)

--Loren Merritt