additional MV candidates

MotionEstimate::motionEstimate() accepts a list of motion candidates:

                               int              numCandidates,
                               const MV *       mvc,

These are supposed to be MV's used by neighboring or coincident blocks, or MV's that might be relevant to this block. We currently only pass in at most three MVs as candidates but we need to be passing in more, particularly when the ME method is hex or dia, as those will not typically find a good MV if the optimal MV is far from the MVP. So the more MV's we provide the better chance our simple ME methods have to find the optimal prediction.

TEncSearch::predInterSearch() calls motionEstimate() (we can ignore the calls from lookahead for now) and it has amvpInfo[][] and mvFieldNeighbours[] which might have interesting MVs to be mined.

The gist of this enhancement is to analyze where those MVs come from and try to come up with an efficiently collected list of MVs without trivial dups (don't include the same MV twice).

If done correctly, there should be an improvement in compression efficiency at very little cost to performance. This extra MV culling might be counter-productive with star search and full search and so it may be useful to avoid it when those are in use. All of this needs to be evaluated with multiple video streams (some with simple motion - johny, some with difficult motion - ducks)

Comments (2)