Re[4]: [XviD-devel] I haven't been here for 4 days and what I see? :)

[Christoph Lampert]

On Mon, 4 Nov 2002, Radek 'sysKin' Czyz wrote:
> This sounds great - and yes, it should make everything way faster.
> I was thinking about something like this (as my next experiment, of
> course):
> - run a check of all macroblocks - if current GMC vector is good
> (below a threshold), we set pMB->mcsel = 1; else = 0;

How do you check if the current GMC vector is good for this block.
I think we should use those blocks which were used to calculate 
initial GMC vector in the beginnning, no matter how "good" their SAD is. 

I will look into a more efficient way of choosing which blocks to use
for this. 

> Also, if SAD is below the threshold sum += SAD;
> 
> This is to check if there is a chance if given macroblock will be
> GMC-ed. If not, we ignore it because it doesn't have to affect the
> search (it will be compensated localy, or even made intra).

SAD is not good for this, because it would favour blocks with
translational motion over those with other movement. We will use SAD 
in the end when GME is finished for mode decision. 

> This is a good point to exclude flat macroblocks, as you said.
> 
> Now, we do a gradient descent using _only_ blocks for which mcsel is
> 1 - so we ignore all macroblocks which don't look like GMC-able, and
> try to minimize sum (computed the same way as before).
> 
> If there is an obvious flaw in the procedure, tell me now so that I
> miss some fun tommorow ;)

I guess it's okay, but we'll have to do a lot of fiddling with parameters
to find a good & fast method.
You might want to look into the "Real-time GMC" article by Smolic if you
didn't already. It shows e..g that you don't need many blocks for GME, 
just some of every area (where possible) etc.

gruel