[x264-devel] Re: Motion Compensation Routines

[rupert.mish at comcast.net]

I meant ME in my previous post. I can see some RDC calls in me.c. But I'd still like to know how the motion vectors are being determined. If there is some reading available on that, it'll be a great help.

Thanks,
- Rupert

 -------------- Original message ----------------------
From: rupert.mish at comcast.net
> Is the MC algo in x264 published somewhere? Does it use rate distortion costs?
> 
> Thanks,
> - Rupert
> 
>  -------------- Original message ----------------------
> From: Loren Merritt <lorenm at u.washington.edu>
> > 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
> > 
> 
> -- 
> This is the x264-devel mailing-list
> To unsubscribe, go to: http://developers.videolan.org/lists.html
> 

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