[XviD-devel] Subpelrefine_Fast

Michael Militzer michael at xvid.org
Sun Sep 14 18:11:00 CEST 2003


Hi,

Quoting Radek Czyz <syskin at ihug.com.au>:

> 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.

yes, you're right. This would be better...
 
> 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?

Hm, we don't need 'second best' that often, right? As said, I don't think
that the fast refinement would be worth to be used for halfpel refinement,
so we'd only need to evaluate the 'second best' for qpel, so doubling all
CheckCandidates might be a bit overkill...

> > 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.

no, I don't think that SATD will be useful for mode decision - real R-D is
very nice for mode decision: it gives optimal results and is still rather
fast. However, R-D introduces a huge slow-down when used in MV search and
gains are often rather low (well, R-D for refinement gives sometimes nice
results also). However, from my experience SATD is often close to R-D, but
is much faster. So VHQ modes 2 or 3 with SATD instead of R-D could make
sense as a good compromise between speed and quality.

BTW: Adding support for SATD shouldn't be hard at all. Skal posted some
SATD code (c + asm I think) to the list some time ago, so we just need to
plug it into XviD...
 
> 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.

ok, so I'd say b-frames + qpel could become significantly faster by just
not performing direct mode search in qpel precision (and there shouldn't
be any quality loss at all when performing the qpel refinement just after
the search has been finished)...

bye,
Michael


More information about the XviD-devel mailing list