Hi, On Sun, Sep 11, 2011 at 10:20 AM, Anton Khirnov <[email protected]> wrote: > On Wed, 7 Sep 2011 16:50:49 -0400, Justin Ruggles <[email protected]> > wrote: >> Based on a patch by Stefano Sabatini. >> git.videolan.org/ffmpeg.git >> commit e280a4da2ae6fd44f0079358ecc5aa08e388a5ed >> --- >> libavcodec/8svx.c | 43 +++++++++++++++++++++---------------------- >> 1 files changed, 21 insertions(+), 22 deletions(-) >> >> diff --git a/libavcodec/8svx.c b/libavcodec/8svx.c >> index 3155171..2f6d2e5 100644 >> --- a/libavcodec/8svx.c >> +++ b/libavcodec/8svx.c >> @@ -32,29 +32,29 @@ >> >> /** decoder context */ >> typedef struct EightSvxContext { >> - int16_t fib_acc; >> - const int16_t *table; >> + uint8_t fib_acc; >> + const int8_t *table; >> } EightSvxContext; >> >> -static const int16_t fibonacci[16] = { -34<<8, -21<<8, -13<<8, -8<<8, >> -5<<8, -3<<8, -2<<8, -1<<8, >> - 0, 1<<8, 2<<8, 3<<8, 5<<8, 8<<8, >> 13<<8, 21<<8 }; >> -static const int16_t exponential[16] = { -128<<8, -64<<8, -32<<8, -16<<8, >> -8<<8, -4<<8, -2<<8, -1<<8, >> - 0, 1<<8, 2<<8, 4<<8, 8<<8, 16<<8, >> 32<<8, 64<<8 }; >> +static const int8_t fibonacci[16] = { -34, -21, -13, -8, -5, -3, -2, -1, >> + 0, 1, 2, 3, 5, 8, 13, 21 >> }; >> +static const int8_t exponential[16] = { -128, -64, -32, -16, -8, -4, -2, -1, >> + 0, 1, 2, 4, 8, 16, 32, 64 >> }; >> >> /** >> * Delta decode the compressed values in src, and put the resulting >> * decoded samples in dst. >> */ >> -static void delta_decode(int16_t *dst, const uint8_t *src, int src_size, >> - int16_t *state, const int16_t *table) >> +static void delta_decode(uint8_t *dst, const uint8_t *src, int src_size, >> + uint8_t *state, const int8_t *table) >> { >> - int val = *state; >> + uint8_t val = *state; >> >> while (src_size--) { >> - uint8_t d = *src++; >> - val = av_clip_int16(val + table[d & 0xF]); >> + int d = *src++; > > Why are you changing the type of d?
Native types are generally easier for the compiler to compile to efficient code. In this case I don't think it makes a difference, so either patch is fine. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
