[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