[XviD-devel] Subpelrefine_Fast

[Radek Czyz]

Hello

Michael wrote

> So as a fix, when qpel_precision is 1, we have to set it to zero, then look
> for the second best (perform these 8 checks), and after this switch qpel
> precision to 1 again.

Alternatively, you can read 'second best' from CurrentQMV and not
double it anymore. I'm saying this because in that case,
CheckCandate16_subpel could only use qpel precision (one less 'if').
If we also removed qpel precision from normal CheckCandate16, and only
use _subpel for qpel refinement (also the 'full' one), we would have 1
another "if" less.

Note that from this point, SubpelRefine_Fast would not use the
original CheckCandate16, ever.

> that's why I created a new CheckCandiate function - I didn't want to change
> or slow down the normal behaviour. After all, checking for a second best
> match slows down CheckCandidate (and adds some new ifs).

OK, there are two ways: 1. double all (almost all - 8 I think. 16 and
8 for p-frames, 16no4v, interpolate, direct, directno4v for b-frames,
16 and 8 for R-D) CheckCandidates and make them all faster, or not
double and make them a little bit slower (if "second best" would only
be evaluated at qpel_precision, it might not be noticable).

All: Which do you think is better?

> I may suggest you try SATD as compare metric for refinement. I'd say it
> should also give good results (close to R-D) while being much faster.

Indeed, something between VHQ2 and VHQ1 (because I don't feel like
writing another ModeDecision for SATD lol).
SADT is very impressive in ffmpeg, as far as I remember.

> Regarding b-frames: b-frames + qpel is currently extremely slow - we should
> try to do something about this. Several things come to mind: we could try
> to do mode decision already after halfpel refinement and only perform qpel
> refinement for one mode after mode decision. It should be checked if direct
> mode delta search is currently performed in qpel precision (I don't know
> out of memory) - if so, this is super-slow. We should then round-down to
> integer or halfpel and refine afterwards. Another idea about mode decision
> would be to introduce some kind of early-stopping: Most of the time, direct
> mode is used and we search for it first. If the found match is good, we
> could simply stop checking any other modes. Also: interpolated mode is only
> rarely used, so maybe we should try to find some heuristic when to perform
> search_interpolate and when not.

This is all true. It's slow because there are usually 4 qpel
refinements (forward, backward and two interpolate) and yes, direct
mode diamond is also in qpel precision... Horrible.

> But surely, it would be great if we'd have a R-D optimized b-frame mode
> decision - just to have an idea of what the optimal solution looks like. I
> really think that there is something to gain from R-D mode decision in b-
> frames (maybe even more than with p-frames).

I tried that and got pretty bad results. However, it appears that for
all R-D stuff in bframes I should assume quantizer-2 as quantizer, it
gets better results - and I haven't tried that for bframe's vhq.

I plan to add it after xvid 1.0. It's mostly copy-and-paste ;)

The in theory, it should be very useful. This is because if R-D can
find any mode that results in all blocks not coded (cbp = 0), it
automatically saves 6 bits just because cbp pattern is not in the
bitstream (it's uncompressed...) and 7th bit because there is no
dquant.

Radek