On Sun, Nov 22, 2015 at 11:40:24AM +0100, Clément Bœsch wrote: > 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
ive seen gcc replace divisions by 2^n by optimized code that used a shift, so it could be that it optimizes it here > > > 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? using /8 might indeed help compilers to choose faster code than for /x > > or maybe you wanted to refer to mpeg where i actually switched from shift > to div? i meant both cases, dunno what they used before > > > 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) i really dont know, i think something mostly symmetrical should be preferred so that for visualization the vectors arent biased in some direction thus a plain >> 3 might be bad > > > > > the patch should be fine either way > > > > > -- > Clément B. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
