[XviD-devel] HUGE ME regressions between beta1 and beta2

[Radek Czyz]

Michael Militzer wrote:

> Well, the idea was: imho, the lambda*MV_bits cost function bears the danger
> that lowers perceived quality even though it increases PSNR. (...)

OK that's a good theory. However, isn't "moving walls" the current 
problem with xvid? Static trails are divx3 problem but we didn't have 
them since forever. By popular vote, robustness of MVs to noise was one 
of my goals for 1.2 development.

> That basically also shouldn't be the case at low quants. At higher quants,
> yes sure, as the old lambda tables were introducing such a huge cost penalty
> that each MB was pinned at MV (0,0). Certainly faster but resulted in
> horrible quality at higher quants.

Yeah I'm puzzled by the slowdown. It doesn't seem to be related to the 
lambda values directly - if I double lambda, speed is still pretty much 
the same. A solid 5% loss, corresponding to ~20% more candidate checks.

The candidate checks happen because fewer predictors repeat and because 
diamonds take more iterations to complete (which partially contradicts btw.)

> Perhaps, one of the early stop criterias don't work properly anymore. E.g.
> the early stop to prevent extensive 8x8 search. I've just seen that these
> early stops use fixed thresholds. Imho, they should be adaptive to be more
> robust...

I turned them off for my investigation. It's not it.

> Actually, there shouldn't be large file size differences. If you look at
> the graphs I plotted, the sample points of before and after the lambda
> change are rather close at low quants. With the new linear lambda tables
> just performing a bit better.

Yes the differences are 1% - 2% of total size so you can't see them on 
graphs. But if you'd look at first pass statistics file, every single 
b-frame is larger with new code. It's non-texture data that is larger, 
but boosting lambda for b-frames seems to have little effect.
It might be the skip (direct_none_mv) decision.

Regards,
Radek