Hi,

2015-02-13 17:49 GMT+01:00 zhaoxiu.zeng <zhaoxiu.z...@gmail.com>:
>      int8_t  acfilter_order;
>      int8_t  acfilter_scaling;
> -    int64_t acfilter_coeffs[16];
> +    int16_t acfilter_coeffs[16];
>      int     acfilter_prevvalues[WMALL_MAX_CHANNELS][16];
>
>      int8_t  mclms_order;
> @@ -818,7 +818,7 @@ static void revert_inter_ch_decorr(WmallDecodeCtx *s, int 
> tile_size)
>  static void revert_acfilter(WmallDecodeCtx *s, int tile_size)
>  {
>      int ich, pred, i, j;
> -    int64_t *filter_coeffs = s->acfilter_coeffs;
> +    int16_t *filter_coeffs = s->acfilter_coeffs;
>      int scaling            = s->acfilter_scaling;
>      int order              = s->acfilter_order;

What worries me here is that the size of those come from the binary
codec. Maybe someone somewhere didn't want to bother, and the above
change is reasonable within what we support, but that sounds like it
could be needed for >16 bits content, cf. mlp.

-- 
Christophe
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to