[Ffmpeg-devel] Motion estimation related refactoring (was: Native H.264 encoder)

Panagiotis Issaris takis.issaris
Thu Jan 18 17:01:22 CET 2007


On Thu, 2007-01-18 at 13:07 +0100, Panagiotis Issaris wrote:
> On Mon, 2006-12-18 at 22:04 +0100, Michael Niedermayer wrote:
> > On Fri, Dec 15, 2006 at 11:34:37PM +0100, Panagiotis Issaris wrote:
> > [...]
> Afterwards, I filtered out all references to members of the embedded
> MotionEstContext and came to this list:
> avctx, b8_stride, bit_rate, current_picture, current_picture_ptr, dsp,
> f_code, flags, frame_bits, height, lambda, lambda2, last_picture,
> last_picture_ptr, linesize, mb_height, mb_stride, mb_width, mb_x, mb_y,
> me, me_method, misc_bits, mv_bits, new_picture, obmc_scratchpad,
> out_format, pict_type, picture_number, p_tex_bits, qscale,
> quarter_sample, rc_context, total_bits, unrestricted_mv, uvlinesize,
> width
> Some of these fields are also available in SnowContext and are mostly
> likely assigned to the equivalently named fields in the MpegEncContext
> only to get motion estimation working:
> avctx, dsp, new_picture, current_picture, last_picture, lambda, lambda2,
> b_width (==mb_width?), b_height (==mb_height?)
> So, the MotionEstContext apparently does not provide enough contextual
> data for the motion estimation functions and therefore they need access
> to the encompassing MpegEncContext. Would that be a good part to focus
> on first? I'd guess one way to solve this would be to move the required
> fields into the MotionEstContext, or another way would be to pass the
> required field in the relevant function calls of the motion estimation
> functions. Both would require quite a lot of changes as the
> encode_frame() functions accesses quite a lot of MpegEncContext fields. 
> Or should a new indepent context be created, that is not specific to
> mpeg (and related codecs) encoding but contains enough info to allow
> motion estimation? But, ... I'd guess the result would be nearly the
> same as moving all the needed stuff to MotionEstContext, right?

The functions that are currently used in the Snow codec which use the
MpegEncContext are the following:

A list of these functions with there parameters:

pict->quality= ff_rate_estimate_qscale(&s->m, 0);

ref_score= ff_epzs_motion_search(&s->m, &ref_mx, &ref_my, P,
0, /*ref_index*/ 0, last_mv, (1<<16)>>shift, level-LOG2_MB_SIZE+4,

ref_score= c->sub_motion_search(&s->m, &ref_mx, &ref_my, ref_score, 0,
0, level-LOG2_MB_SIZE+4, block_w);

ref_score= ff_get_mb_score(&s->m, ref_mx, ref_my, 0, 0,
level-LOG2_MB_SIZE+4, block_w, 0);

I am currently looking at these functions and trying to figure out,
which fields are needed for each. Hoping that I will be able to split
MpegEncContext in some smaller, simpler and more logically coherent

I'm going to post a lot regarding this possible refactoring, as I'm
hoping others will jump in on this discussion. And also because I want
to show the direction I'm heading in as soon as possible, so that any
stupid directions I might take, will be cut off by someones remark as
soon as possible :)

With friendly regards,

vCard: http://www.issaris.org/pi.vcf
Public key: http://www.issaris.org/pi.key

More information about the ffmpeg-devel mailing list