[x264-devel] Re: Motion Compensation Routines

[Loren Merritt]

On Thu, 23 Nov 2006, rupert.mish at comcast.net wrote:

> I plan to try out a motion prediction algorithm.  I'd like to know what 
> routines to start with and what data structures to access for the frames 
> and blocks? Just to get a handle, I'll probably have to come back with 
> the specifics. I'd appreciate getting help from you folks.

All of the following is in common/mc.c

x264's motion compensation framework includes some optimizations that are 
specific to h264. h264's motion compensation first does a 6tap filter to 
produce halfpel samples from pixels, and then each qpel sample is an 
average of two halfpel samples. So x264 does the same: 6tap filter for all 
3 halfpel offsets and store the results, and then each later request for a 
motion-compensated block just computes the halfpel-to-qpel step if 
necessary, or returns a pointer to one of the pre-computed halfpel planes.

If your proposed mc algo fits in the same framework, then the way to 
implement it is: modify mc_hh, mc_hv, mc_hc to do your halfpel 
interpolation, and modify mc_luma and get_ref to do your halfpel-to-qpel 
interpolation.
If not: ignore the halfpel step. mc_luma should perform the whole 
interpolation process, using only src[0] (which is the original pixels) 
not src[1..3] (which are the halfpel planes). get_ref should just call 
mc_luma.

Chroma doesn't follow that framework, so motion_compensation_chroma just 
takes some pixels and returns some interpolated samples.

In all cases, the mc functions are given a pointer to the pixels they're 
supposed to work with, so you don't have to worry about where the pixels 
are stored.

--Loren Merritt

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html