[FFmpeg-cvslog] r18599 - trunk/libavcodec/xan.c

[Reimar Döffinger]

On Sat, Apr 18, 2009 at 03:34:02AM +0200, Michael Niedermayer wrote:
> On Fri, Apr 17, 2009 at 10:07:31PM +0200, Reimar D?ffinger wrote:
> > On Fri, Apr 17, 2009 at 10:05:27PM +0200, reimar wrote:
> > > Author: reimar
> > > Date: Fri Apr 17 22:05:27 2009
> > > New Revision: 18599
> > > 
> > > Log:
> > > Use sign_extend function instead of reimplementing it.
> > > 
> > > Modified:
> > >    trunk/libavcodec/xan.c
> > > 
> > > Modified: trunk/libavcodec/xan.c
> > > ==============================================================================
> > > --- trunk/libavcodec/xan.c	Fri Apr 17 22:01:45 2009	(r18598)
> > > +++ trunk/libavcodec/xan.c	Fri Apr 17 22:05:27 2009	(r18599)
> > > @@ -333,16 +333,10 @@ static void xan_wc3_decode_frame(XanCont
> > >              }
> > >          } else {
> > >              /* run-based motion compensation from last frame */
> > > -            motion_x = *vector_segment >> 4;
> > > -            motion_y = *vector_segment & 0xF;
> > > +            motion_x = sign_extend(*vector_segment >> 4,  4);
> > > +            motion_y = sign_extend(*vector_segment & 0xF, 4);
> > 
> > Someone forgot to document sign_extend, should I be doing the "& 0xF"
> > or can I assume that any future optimized implementation will flush
> > the upper bits, too?
> 
> the upper bits must be cleared

Do you mean "must have been cleared by the caller" or "must be cleared
by the function"? This sounds like the latter, but

> its possible to implement sign extend with 1 + and 1 xor if the shift
> is constant, and this may be faster than the 2 shifts ...

that would only work if you meant the former AFAICT.