[MPlayer-cvslog] CVS: main/libmpcodecs ve_lavc.c,1.111,1.112

[D Richard Felker III]

On Thu, Mar 03, 2005 at 04:26:42PM -0800, Loren Merritt wrote:
> If vqcomp=1, then rc_eq=tex^1=tex, so 2pass allocates to each frame the 
> number of bits needed to encode them all at the same QP.
> If vqcomp=0, then rc_eq=tex^0=1, so 2pass allocates the same number of 
> bits to each frame, i.e. CBR. (Actually, this is worse than 1pass CBR in 
> terms of quality; CBR can vary within its allowed buffer size, while 
> vqcomp=0 tries to make each frame exactly the same size.)

I disagree with the claim that it's worse. In 1pass mode, a complex
scene will use up way too many bits, and the next 20-30 seconds or
more will get encoded at q=31 trying to bring the average bitrate back
down to the nominal level. Of course this looks horrible. Using a tiny
vbv buffer size and strict minrate/maxrate will alleviate the problem,
but that setup also seems to make the quantizer shoot way up on every
I-frame, giving a really ugly pulsating noise effect. I don't know if
2pass cbr (qcomp==0) is any better; I've never tried it.

> While the actual selection of a good value of vqcomp is experimental, the 
> following underlying factors determine the result:
> Arguing towards CQP: You want the movie to be somewhere approaching 
> constant quality; oscillating quality is even more annoying than constant 
> low quality.

Oscillating is bad, but in 2pass mode, I've never seen "oscillating"
quality. Instead, I've just seen a few excessively complex scenes with
lots of intentional random noise and motion get very blocky...and
although this is annoying, it's probably less annoying than having
ringing or blocks in all your still frames.

> (However, constant quality does not mean constant PSNR nor 
> constant QP.

I'd be very interested in a constant-PSRN rate control engine, to see
how it would perform in terms of perceptual quality..

> Details are less noticeable in high-motion scenes, so you can 
> get away with somewhat higher QP in high-complexity frames for the same 
> percieved quality.)

Agree.

> Now for why the 1st pass ratecontrol method matters:
> The number of bits at constant quant is as good a measure of complexity as
> any other simple formula for the purpose of allocating bits. But it's not
> perfect for predicting which QP will produce the desired number of bits.
> Bits are approximately inversely proportional to QP, but the exact scaling
> is non-linear, and depends on the amount of detail/noise, the complexity of
> motion, the quality of previous frames, and other stuff not measured by the
> ratecontrol. So it predicts best when the QP used for a given frame in the
> 2nd pass is close to the QP used in the 1st pass. When the prediction is
> wrong, lavc needs to distribute the surplus or deficit of bits among future
> frames, which means that they too deviate from the planned distribution.
> Obviously, with vqcomp=1 you can get the 1st pass QPs very close by using
> CQP, and with vqcomp=0 a CBR 1st pass is very close. But with vqcomp=0.5
> it's more ambiguous. The accepted wisdom is that CBR is better for
> vqcomp=0.5, mostly because you then don't have to guess a QP in advance.
> But with vqcomp=0.6 or 0.7, the 2nd pass QPs vary less, so a CQP 1st pass
> (with the right QP) will be a better predictor than CBR.

Maybe. I'd like to see some empirical results on this..

BTW another thing that would be really useful, especially now that we
have multipass mode: lavc should output information on the difference
(peak, sse, and sad) between the original qp distribution curve from
the previous pass, and the new one. Actually this could be done
externally, just processing the log file and linking to ratecontrol.c.
It would be good to be able to see how fast multipass mode is
converging, so you don't run needless passes that won't improve
anything..

> To make it more confusing, 1pass CBR uses the same rc_eq with a different
> meaning. In CBR, we don't have a real encode to estimate from, so "tex" is
> calculated from the full-pixel precision motion-compensation residual.
> While the number of bits allocated to a given frame is decided by the rc_eq
> just like in 2nd pass, the target bitrate is constant (instead of being the
> sum of per-frame rc_eq values). So the scaling factor (which is constant in
> 2nd pass) now varies in order to keep the local average bitrate near the
> CBR target. So vqcomp does affect CBR, though it only determines the local
> allocation of bits, not the long-term allocation.

There's also some evil black magic that makes it treat I frames and B
frames differently, resulting in the ugly pulsating noise when trying
to make VCDs. I found some options to work around this a bit, but it's
difficult.. IMO there must be some more sane way to do 1pass rate
control...

Rich