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

[Clément Bœsch]

On Sun, Nov 22, 2015 at 04:27:02PM +0100, Michael Niedermayer wrote:
[...]
> > > 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< > 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
> 

So I kept the division, but hardcoded the 8 in snow.

Applied, thanks

BTW: can't we get more information on the "direction" (that is, the source
ref) for h264? Currently in the mpegvideo code, we have two ref possible
(forward and backward), but h264 (and maybe other similar codecs sharing
that code) can pick from more refs, right?

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Michael Niedermayer]

On Mon, Nov 23, 2015 at 05:07:30PM +0100, Clément Bœsch wrote:
> On Mon, Nov 23, 2015 at 03:54:19PM +0100, Michael Niedermayer wrote:
> > On Mon, Nov 23, 2015 at 11:01:02AM +0100, Clément Bœsch wrote:
> > > On Sun, Nov 22, 2015 at 04:27:02PM +0100, Michael Niedermayer wrote:
> > > [...]
> > > > > > 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< > > > > 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
> > > > 
> > > 
> > > So I kept the division, but hardcoded the 8 in snow.
> > > 
> > > Applied, thanks
> > > 
> > > BTW: can't we get more information on the "direction" (that is, the source
> > > ref) for h264? Currently in the mpegvideo code, we have two ref possible
> > > (forward and backward), but h264 (and maybe other similar codecs sharing
> > > that code) can pick from more refs, right?
> > 
> > yes
> > 
> 
> where can this information be obtained?

maybe H264Picture->field_poc / poc

note, the relation between the reference indexes and the H264Picture
could change per slice in theory

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Clément Bœsch]

On Mon, Nov 23, 2015 at 03:54:19PM +0100, Michael Niedermayer wrote:
> On Mon, Nov 23, 2015 at 11:01:02AM +0100, Clément Bœsch wrote:
> > On Sun, Nov 22, 2015 at 04:27:02PM +0100, Michael Niedermayer wrote:
> > [...]
> > > > > 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< > > > 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
> > > 
> > 
> > So I kept the division, but hardcoded the 8 in snow.
> > 
> > Applied, thanks
> > 
> > BTW: can't we get more information on the "direction" (that is, the source
> > ref) for h264? Currently in the mpegvideo code, we have two ref possible
> > (forward and backward), but h264 (and maybe other similar codecs sharing
> > that code) can pick from more refs, right?
> 
> yes
> 

where can this information be obtained?

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Michael Niedermayer]

On Mon, Nov 23, 2015 at 11:01:02AM +0100, Clément Bœsch wrote:
> On Sun, Nov 22, 2015 at 04:27:02PM +0100, Michael Niedermayer wrote:
> [...]
> > > > 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< > > 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
> > 
> 
> So I kept the division, but hardcoded the 8 in snow.
> 
> Applied, thanks
> 
> BTW: can't we get more information on the "direction" (that is, the source
> ref) for h264? Currently in the mpegvideo code, we have two ref possible
> (forward and backward), but h264 (and maybe other similar codecs sharing
> that code) can pick from more refs, right?

yes

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Michael Niedermayer]

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< 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

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

[Clément Bœsch]

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 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.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Clément Bœsch]

On Fri, Nov 20, 2015 at 10:36:36AM +0100, Clément Bœsch wrote:
> On Fri, Nov 20, 2015 at 10:33:04AM +0100, Clément Bœsch wrote:
> [...]
> > > i think this doesnt support libavcodec/tpeldsp.c as used in svq3
> > > that would need a motion_xy / 3
> > > 
> > > i might be missing something but
> > > 
> > >  * Motion vector
> > >  * src_x = dst_x + motion_x / motion_scale
> > >  * src_y = dst_y + motion_y / motion_scale
> > >  */
> > > int32_t motion_x, motion_y;
> > > uint8_t motion_scale;   // This is almost always a power of 2
> > > 
> > > should be enough to support all things
> > > 
> > 
> > ok, so always a div then
> > 
> > > The "*motion_scale" should not be needed, the exportet vectors
> > > can just be multiplied up if thats needed
> > 
> > what is the range of mv_scale in snow? how much precision i'm going to
> > loose by doing avmv->motion_scale = mv_scale/8?
> > 
> 
> ah wait my bad, forget this.
> 
> note: can't we make the motion_scale always a power of two by
> pre-multiplying motion_[xy]?
> 

I can't math. New patch incoming.

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Clément Bœsch]

On Fri, Nov 20, 2015 at 10:33:04AM +0100, Clément Bœsch wrote:
[...]
> > i think this doesnt support libavcodec/tpeldsp.c as used in svq3
> > that would need a motion_xy / 3
> > 
> > i might be missing something but
> > 
> >  * Motion vector
> >  * src_x = dst_x + motion_x / motion_scale
> >  * src_y = dst_y + motion_y / motion_scale
> >  */
> > int32_t motion_x, motion_y;
> > uint8_t motion_scale;   // This is almost always a power of 2
> > 
> > should be enough to support all things
> > 
> 
> ok, so always a div then
> 
> > The "*motion_scale" should not be needed, the exportet vectors
> > can just be multiplied up if thats needed
> 
> what is the range of mv_scale in snow? how much precision i'm going to
> loose by doing avmv->motion_scale = mv_scale/8?
> 

ah wait my bad, forget this.

note: can't we make the motion_scale always a power of two by
pre-multiplying motion_[xy]?

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Clément Bœsch]

On Mon, Nov 16, 2015 at 02:49:05AM +0100, Michael Niedermayer wrote:
> On Thu, Nov 12, 2015 at 03:03:33PM +0100, Clément Bœsch wrote:
> > ---
> >  libavcodec/mpegvideo.c | 36 +---
> >  libavcodec/snowdec.c   |  4 
> >  libavfilter/vf_codecview.c |  7 +--
> >  libavutil/motion_vector.h  |  8 
> >  libavutil/version.h|  2 +-
> >  5 files changed, 39 insertions(+), 18 deletions(-)
> > 
> > diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
> > index 96634ec..9ba1e09 100644
> > --- a/libavcodec/mpegvideo.c
> > +++ b/libavcodec/mpegvideo.c
> > @@ -1556,15 +1556,21 @@ static void draw_arrow(uint8_t *buf, int sx, int 
> > sy, int ex,
> >  
> >  static int add_mb(AVMotionVector *mb, uint32_t mb_type,
> >int dst_x, int dst_y,
> > -  int src_x, int src_y,
> > +  int motion_x, int motion_y, int motion_shift,
> >int direction)
> >  {
> >  mb->w = IS_8X8(mb_type) || IS_8X16(mb_type) ? 8 : 16;
> >  mb->h = IS_8X8(mb_type) || IS_16X8(mb_type) ? 8 : 16;
> > -mb->src_x = src_x;
> > -mb->src_y = src_y;
> > +
> > +mb->motion_x = motion_x;
> > +mb->motion_y = motion_y;
> > +mb->motion_scale = 1;
> > +mb->motion_shift = motion_shift;
> > +
> >  mb->dst_x = dst_x;
> >  mb->dst_y = dst_y;
> > +mb->src_x = dst_x + (motion_x >> motion_shift);
> > +mb->src_y = dst_y + (motion_y >> motion_shift);
> >  mb->source = direction ? 1 : -1;
> >  mb->flags = 0; // XXX: does mb_type contain extra information that 
> > could be exported here?
> >  return 1;
> > @@ -1603,43 +1609,43 @@ void ff_print_debug_info2(AVCodecContext *avctx, 
> > AVFrame *pict, uint8_t *mbskip_
> >  int sy = mb_y * 16 + 4 + 8 * (i >> 1);
> >  int xy = (mb_x * 2 + (i & 1) +
> >(mb_y * 2 + (i >> 1)) * mv_stride) 
> > << (mv_sample_log2 - 1);
> > -int mx = (motion_val[direction][xy][0] >> 
> > shift) + sx;
> > -int my = (motion_val[direction][xy][1] >> 
> > shift) + sy;
> > -mbcount += add_mb(mvs + mbcount, mb_type, sx, 
> > sy, mx, my, direction);
> > +int mx = motion_val[direction][xy][0];
> > +int my = motion_val[direction][xy][1];
> > +mbcount += add_mb(mvs + mbcount, mb_type, sx, 
> > sy, mx, my, shift, direction);
> >  }
> >  } else if (IS_16X8(mb_type)) {
> >  for (i = 0; i < 2; i++) {
> >  int sx = mb_x * 16 + 8;
> >  int sy = mb_y * 16 + 4 + 8 * i;
> >  int xy = (mb_x * 2 + (mb_y * 2 + i) * 
> > mv_stride) << (mv_sample_log2 - 1);
> > -int mx = (motion_val[direction][xy][0] >> 
> > shift);
> > -int my = (motion_val[direction][xy][1] >> 
> > shift);
> > +int mx = motion_val[direction][xy][0];
> > +int my = motion_val[direction][xy][1];
> >  
> >  if (IS_INTERLACED(mb_type))
> >  my *= 2;
> >  
> > -mbcount += add_mb(mvs + mbcount, mb_type, sx, 
> > sy, mx + sx, my + sy, direction);
> > +mbcount += add_mb(mvs + mbcount, mb_type, sx, 
> > sy, mx, my, shift, direction);
> >  }
> >  } else if (IS_8X16(mb_type)) {
> >  for (i = 0; i < 2; i++) {
> >  int sx = mb_x * 16 + 4 + 8 * i;
> >  int sy = mb_y * 16 + 8;
> >  int xy = (mb_x * 2 + i + mb_y * 2 * mv_stride) 
> > << (mv_sample_log2 - 1);
> > -int mx = motion_val[direction][xy][0] >> shift;
> > -int my = motion_val[direction][xy][1] >> shift;
> > +int mx = motion_val[direction][xy][0];
> > +int my = motion_val[direction][xy][1];
> >  
> >  if (IS_INTERLACED(mb_type))
> >  my *= 2;
> >  
> > -mbcount += add_mb(mvs + mbcount, mb_type, sx, 
> > sy, mx + sx, my + sy, direction);
> > +mbcount += add_mb(mvs + mbcount, mb_type, sx, 
> > sy, mx, my, shift, direction);
> >  }
> >  } else {
> >int sx = mb_x * 16 + 8;
> >int sy = mb_y * 16 + 8;
> >int xy = (mb_x + mb_y * mv_stride) << 
> > mv_sample_log2;
> > -  int mx = (motion_val[direction][xy][0]>>shift) + 
> > sx;
> 

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

[Michael Niedermayer]

On Thu, Nov 12, 2015 at 03:03:33PM +0100, Clément Bœsch wrote:
> ---
>  libavcodec/mpegvideo.c | 36 +---
>  libavcodec/snowdec.c   |  4 
>  libavfilter/vf_codecview.c |  7 +--
>  libavutil/motion_vector.h  |  8 
>  libavutil/version.h|  2 +-
>  5 files changed, 39 insertions(+), 18 deletions(-)
> 
> diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
> index 96634ec..9ba1e09 100644
> --- a/libavcodec/mpegvideo.c
> +++ b/libavcodec/mpegvideo.c
> @@ -1556,15 +1556,21 @@ static void draw_arrow(uint8_t *buf, int sx, int sy, 
> int ex,
>  
>  static int add_mb(AVMotionVector *mb, uint32_t mb_type,
>int dst_x, int dst_y,
> -  int src_x, int src_y,
> +  int motion_x, int motion_y, int motion_shift,
>int direction)
>  {
>  mb->w = IS_8X8(mb_type) || IS_8X16(mb_type) ? 8 : 16;
>  mb->h = IS_8X8(mb_type) || IS_16X8(mb_type) ? 8 : 16;
> -mb->src_x = src_x;
> -mb->src_y = src_y;
> +
> +mb->motion_x = motion_x;
> +mb->motion_y = motion_y;
> +mb->motion_scale = 1;
> +mb->motion_shift = motion_shift;
> +
>  mb->dst_x = dst_x;
>  mb->dst_y = dst_y;
> +mb->src_x = dst_x + (motion_x >> motion_shift);
> +mb->src_y = dst_y + (motion_y >> motion_shift);
>  mb->source = direction ? 1 : -1;
>  mb->flags = 0; // XXX: does mb_type contain extra information that could 
> be exported here?
>  return 1;
> @@ -1603,43 +1609,43 @@ void ff_print_debug_info2(AVCodecContext *avctx, 
> AVFrame *pict, uint8_t *mbskip_
>  int sy = mb_y * 16 + 4 + 8 * (i >> 1);
>  int xy = (mb_x * 2 + (i & 1) +
>(mb_y * 2 + (i >> 1)) * mv_stride) << 
> (mv_sample_log2 - 1);
> -int mx = (motion_val[direction][xy][0] >> shift) 
> + sx;
> -int my = (motion_val[direction][xy][1] >> shift) 
> + sy;
> -mbcount += add_mb(mvs + mbcount, mb_type, sx, 
> sy, mx, my, direction);
> +int mx = motion_val[direction][xy][0];
> +int my = motion_val[direction][xy][1];
> +mbcount += add_mb(mvs + mbcount, mb_type, sx, 
> sy, mx, my, shift, direction);
>  }
>  } else if (IS_16X8(mb_type)) {
>  for (i = 0; i < 2; i++) {
>  int sx = mb_x * 16 + 8;
>  int sy = mb_y * 16 + 4 + 8 * i;
>  int xy = (mb_x * 2 + (mb_y * 2 + i) * mv_stride) 
> << (mv_sample_log2 - 1);
> -int mx = (motion_val[direction][xy][0] >> shift);
> -int my = (motion_val[direction][xy][1] >> shift);
> +int mx = motion_val[direction][xy][0];
> +int my = motion_val[direction][xy][1];
>  
>  if (IS_INTERLACED(mb_type))
>  my *= 2;
>  
> -mbcount += add_mb(mvs + mbcount, mb_type, sx, 
> sy, mx + sx, my + sy, direction);
> +mbcount += add_mb(mvs + mbcount, mb_type, sx, 
> sy, mx, my, shift, direction);
>  }
>  } else if (IS_8X16(mb_type)) {
>  for (i = 0; i < 2; i++) {
>  int sx = mb_x * 16 + 4 + 8 * i;
>  int sy = mb_y * 16 + 8;
>  int xy = (mb_x * 2 + i + mb_y * 2 * mv_stride) 
> << (mv_sample_log2 - 1);
> -int mx = motion_val[direction][xy][0] >> shift;
> -int my = motion_val[direction][xy][1] >> shift;
> +int mx = motion_val[direction][xy][0];
> +int my = motion_val[direction][xy][1];
>  
>  if (IS_INTERLACED(mb_type))
>  my *= 2;
>  
> -mbcount += add_mb(mvs + mbcount, mb_type, sx, 
> sy, mx + sx, my + sy, direction);
> +mbcount += add_mb(mvs + mbcount, mb_type, sx, 
> sy, mx, my, shift, direction);
>  }
>  } else {
>int sx = mb_x * 16 + 8;
>int sy = mb_y * 16 + 8;
>int xy = (mb_x + mb_y * mv_stride) << 
> mv_sample_log2;
> -  int mx = (motion_val[direction][xy][0]>>shift) + 
> sx;
> -  int my = (motion_val[direction][xy][1]>>shift) + 
> sy;
> -  mbcount += add_mb(mvs + mbcount, mb_type, sx, sy, 
> mx, my, direction);
> +  int mx = motion_val[direction][xy][0];
> +