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

Reimar Döffinger Reimar.Doeffinger
Fri Apr 17 22:54:52 CEST 2009


On Fri, Apr 17, 2009 at 09:49:12PM +0100, M?ns Rullg?rd wrote:
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> 
> > On Fri, Apr 17, 2009 at 09:21:21PM +0100, M?ns Rullg?rd wrote:
> >> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> >> 
> >> > 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?
> >> 
> >> What do you mean?  sign_extend() fills the size of an int, whatever
> >> that happens to be, typically 32 bits.
> >
> > Let me say it differently:
> > It is not documented if future implementations may assume
> > val < (1 << bits)
> 
> I would say they may not.

Well, it's maybe more readable like this anyway so I'll leave it at
least until the situation is written in stone... uh I mean in
documentation ;-)

> > for example for a fixed value of "bits" and a machine with extremely slow
> > shifts and bit operations, someone might have the idea of implementing
> > it as
> >> if (val & (1 << (bits-1)))
> >>     val += ~0 << bits;
> 
> If shifts are slow, that's two of them and thus doubly slow.

Well, I had to make up an example, but I also said "fixed value of
"bits"" which means those shifts can be calculated at compile-time
(and that optimization might be using one of those gcc hacks to use
different code if "bits" is not a constant).



More information about the ffmpeg-cvslog mailing list