[Ffmpeg-devel] redundant code in mpegvideo.c, and a question about encode_mb()

giemu_tarudi at yahoo.co.jp giemu_tarudi
Thu Sep 7 21:42:38 CEST 2006


One identical line is found in 2 different places in mpegvideo.c, and in the
case of encoding it seems redundant:
    copy_picture(&s->current_picture, s->current_picture_ptr);

My suggestion for the one in MPV_frame_start() is to move the following a few
lines above inside if(!s->encoding){...}

    s->current_picture_ptr->pict_type= s->pict_type;
//    if(s->flags && CODEC_FLAG_QSCALE) 
  //      s->current_picture_ptr->quality= s->new_picture_ptr->quality;
    s->current_picture_ptr->key_frame= s->pict_type == I_TYPE;

    copy_picture(&s->current_picture, s->current_picture_ptr);

Indeed, for encoding,
    s->pict_type= s->new_picture.pict_type;
(which is the same)

And key_frame is set later anyway.

I do have one question, too.

static void encode_mb(MpegEncContext *s, int motion_x, int motion_y)
uses 2 buffers for motion compensation of non I frames:

ptr_y = s->new_picture.data[0] + (mb_y * 16 * wrap_y) + mb_x * 16;
dest_y  = s->dest[0];

The latter points to s->current_picture.data[0]

So, how come the following works given that src and dest point to 2 locations
in memory 16 bytes apart:
MPV_motion(s, dest_y, dest_cb, dest_cr, 0, s->last_picture.data, op_pix,
op_qpix);
...
s->dsp.diff_pixels(s->block[0], ptr_y, dest_y, wrap_y);

This is where I checked the pointers, only 16 bytes apart.

If anyone understands, please tell me.

HTH

--------------------------------------
For All Sports Lovers!
http://pr.mail.yahoo.co.jp/yells/




More information about the ffmpeg-devel mailing list