[XviD-devel] optimizations

[Christoph Lampert]

On Tue, 8 Apr 2003, Radek Czyz wrote:
> And now, I'll write something I wanted to write a few days ago but
> forgot.
> It's about GMC. I tried to incorporate GMC to BITS and it didn't work.
> The problem was that BITS decision pays huge attention to vector
> prediction. When I changed mcsel, I also changes the average vector,
> and this changes prediction for other blocks. The result was very bad.
> So if you want to know my opinion, I say you can't do ME first, then
> GMC on the basis of vectors, then mcsel. Pre-pass is the only way. And
> now the tricky part: we're doing pre-pass already! It's called p/b/i
> decision. It's very fast, reasonably accurate (well don't count on it
> too much), and it tries to find the best match, it doesn't try to
> limit vector length. Exactly what you need for gmc.

No, actually not. I checked it, too. The search is too coarse to be useful
for GME, where the vectors have to be fairly accurate. 
But I will change GME anyway: You are right that GME should be done
_before_ block ME. 
Since my refinement works rather well (and isn't _too_ slow anymore), 
I'm going to change ME for XVID_GMC to:

1) If GME_REFINE and previoous frame GME is available, use it as
   starting point, and refine (3 warp points).

2) If GME_REFINE, but no previous GME available, do a quick
   16x16(!) halfpel(!) ME analysis and estimate GME startpoint (2 wp), 
   refine that (3 wp). 

3) If !GME_REFINE, do as 2), but without refine. 
   This mode's results are rather bad, but you might have noticed that
   yourself in current GME. 

4) If GME is translational only, the frame becomes P_VOP instead of S_VOP.
   I simply couldn't find a single clip where translational S_VOP was 
   beneficial. 

gruel

P.S. @skal: Are you sure the parameters that are generated in 3 wp 
     mode when only 2 wp would be needed (num_wp==2) is correct? 
     It seems to me that scaling for duv[2] is wrong (ffmpeg shows 
     errors), but when num_wp==2 is treated like 3, it's gone.