On Sun, Nov 22, 2015 at 03:24:55AM +0100, Michael Niedermayer wrote: [...] > > diff --git a/libavcodec/snowdec.c b/libavcodec/snowdec.c > > index 1b288dd..5eb775a 100644 > > --- a/libavcodec/snowdec.c > > +++ b/libavcodec/snowdec.c > > @@ -104,8 +104,11 @@ static av_always_inline void > > predict_slice_buffered(SnowContext *s, slice_buffer > > avmv->h = block_h; > > avmv->dst_x = block_w*mb_x - block_w/2; > > avmv->dst_y = block_h*mb_y - block_h/2; > > - avmv->src_x = avmv->dst_x + (bn->mx * s->mv_scale)/8; > > - avmv->src_y = avmv->dst_y + (bn->my * s->mv_scale)/8; > > + avmv->motion_scale = 1 << 3; > > + avmv->motion_x = bn->mx * s->mv_scale; > > + avmv->motion_y = bn->my * s->mv_scale; > > > + avmv->src_x = avmv->dst_x + avmv->motion_x / > > avmv->motion_scale; > > + avmv->src_y = avmv->dst_y + avmv->motion_y / > > avmv->motion_scale; > > does gcc optimize these divisions out ?
i doubt it, as motion_[xy] is signed > if not it might be better to avoid them. > there is a /8 in the original code, but maybe you meant using 8 instead of avmv->motion_scale? or maybe you wanted to refer to mpeg where i actually switched from shift to div? > IIUC src_x/y are only an approximation, as the exact motion vector > isnt an integer in fullpel units so it would be mostly cosmetic > if x + 4 >> 8, or /8 is used yes mpeg used x >> n, i replaced with x / (1<<n), but i could switch back to the original shift, or even do x+(1<<(n-1))>>n if you want some rounding. same for snow... what would you prefer? i have no real opinion, this code doesn't interfere with normal decoding anyway (so performance is less relevant) > > the patch should be fine either way > -- Clément B.
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list email@example.com http://ffmpeg.org/mailman/listinfo/ffmpeg-devel