Young Han Lee <[email protected]> writes:

> Hi
>
> On Mon, May 16, 2011 at 12:41 AM, Justin Ruggles
> <[email protected]>wrote:
>
>> ---
>> This fixes fate-aac-ap05_48 on PPC. Might fix it on ARM too.
>>
>>  libavcodec/aac.h    |    2 +-
>>  libavcodec/aacdec.c |    6 +++---
>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>
>
>> diff --git a/libavcodec/aac.h b/libavcodec/aac.h
>> index ecb8191..76b6a78 100644
>> --- a/libavcodec/aac.h
>> +++ b/libavcodec/aac.h
>> @@ -227,7 +227,7 @@ typedef struct {
>>      DECLARE_ALIGNED(32, float,   coeffs)[1024];     ///< coefficients for
>> IMDCT
>>      DECLARE_ALIGNED(32, float,   saved)[1024];      ///< overlap
>>      DECLARE_ALIGNED(32, float,   ret)[2048];        ///< PCM output
>> -    DECLARE_ALIGNED(16, int16_t, ltp_state)[3072];  ///< time signal for
>> LTP
>> +    DECLARE_ALIGNED(16, float,   ltp_state)[3072];  ///< time signal for
>> LTP
>>      PredictorState predictor_state[MAX_PREDICTORS];
>>  } SingleChannelElement;
>>
>> diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
>> index d26cce9..5f9dd83 100644
>> --- a/libavcodec/aacdec.c
>> +++ b/libavcodec/aacdec.c
>> @@ -1820,9 +1820,9 @@ static void update_ltp(AACContext *ac,
>> SingleChannelElement *sce)
>>              saved_ltp[i + 512] = ac->buf_mdct[1023 - i] * lwindow[511 -
>> i];
>>      }
>>
>> -    memcpy(sce->ltp_state, &sce->ltp_state[1024], 1024 * sizeof(int16_t));
>> -    ac->fmt_conv.float_to_int16(&(sce->ltp_state[1024]), sce->ret,  1024);
>> -    ac->fmt_conv.float_to_int16(&(sce->ltp_state[2048]), saved_ltp, 1024);
>> +    memcpy(sce->ltp_state,      sce->ltp_state+1024, 1024 *
>> sizeof(*sce->ltp_state));
>> +    memcpy(sce->ltp_state+1024, sce->ret,            1024 *
>> sizeof(*sce->ltp_state));
>> +    memcpy(sce->ltp_state+2048, saved_ltp,           1024 *
>> sizeof(*sce->ltp_state));
>>  }
>>
>>  /**
>>
>
> The buffer for ltp (ltp_state) is defined in "short" type in the reference
> software and the document.

Reference software is awful more often than not, and AAC decoding isn't
precisely specified, so being more accurate than the reference code is
allowed.

> Of course "float" type does not make serious error but just rounding error.

A float can represent all values an int16_t can, so this change can only
make it more accurate.

> So I used "int16_t" type because I should follow the document and I believed
> "int16_t" was smaller than "float".

It is smaller, but it's also less accurate and converting back and forth
takes extra time.

-- 
Måns Rullgård
[email protected]
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to