Hi, 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: ff_epzs_motion_search ff_get_mb_score ff_init_me ff_rate_control_init ff_rate_estimate_qscale h263_encode_init sub_motion_search A list of these functions with there parameters: h263_encode_init(&s->m); ff_init_me(&s->m); ff_rate_control_init(&s->m) 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, block_w); 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 structures. 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, Takis -- vCard: http://www.issaris.org/pi.vcf Public key: http://www.issaris.org/pi.key
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4