Re[4]: [XviD-devel] New Motion Estimation (from sysKin) committed to branch

[Michael Militzer]

Hi,

> > 2) do INTER/INTER4V decision before any halfpel refine: Idea is to first
do
> > the normal search16, then do NO halfpel refine (instead maybe do the
early
> > INTRA/INTER decision mentioned above) and start the 4MV search
(search8).
>
> The point is that every 16x16 check is important for inter4v search
> and inter/inter4v decision. In fact, halfpel refinement seems to be
> most important of all. 16x16 refinemnt is not wasted if inter4v is
> used - it's very important for the decision.
> What can be done, is skipping 8x8 refinement. However, I don't believe
> that it can be done while still keeping the same PSNR, because without
> 8x8 refinement (which can be turned off by motion flags) inter4v mode
> is rarely used.
> Please note that 8x8 refinement is very fast now (which desn't mean
> that it will be fast for qpel, I admit).

ok, then let's do the halfpel16_refine. But we could still try to do a broad
INTER/INTER4V decision before halfpel8_refine: if the sum of SAD8s +
calc_delta_8 is much higher than sad16 then mode = INTER and terminate
search, else do the halfpel8 refinements, do normal INTER/INTER4V decision
again...
Don't know if this could be faster, but maybe it's worth a try...

> > 3) I'd like to have a small data structure where the SADs of the
neighboured
> > blocks (top, bottom, left, right) of the current best match are stored.
> > Well, while I think about it, even better would be all 8 neighbours.
This
> > could allow faster qpel refinement...
>
> Yeah, I thought about it. I think this can be done by modifying all
> diamonds. It is possible to 'peek' last SAD found by last
> CheckCandate16() at this moment (it's under Data->temp[0] or something
> like that) and I can modify all CheckCandidate()s to support it.

good

> PS: another thing to be concidered is Bframe quant ratio. We have to
> decide about it, and my current opinion is that b-frames should have
> current quant + 2; maybe +1 if P-frame quant is 2. Not more than +3 in
> any case.
> Once sequences like PBBBBP are quite possible in the movie (with
> dynamic P/B) lower b-frame quant may look really bad :(

yes, b-frame quant shouldn't be much higher than p-frame quant if we have
lot of b-frames in a row...

bye,
Michael

PS: I've just committed the sad16v_mmx code. It seems to work, but please
test yourself...