[FFmpeg-devel] [PATCH] avutil/motion_vector: export subpel motion information

Michael Niedermayer michaelni at gmx.at
Sun Nov 22 16:27:02 CET 2015


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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151122/69a94523/attachment.sig>


More information about the ffmpeg-devel mailing list