[FFmpeg-soc] AAC decoder compilation warnings

[Robert Swain]

Hello,

It seems compiler warnings that could probably be ignored should be
silenced as long as it does not obfuscate or slow down the code. The
current warnings in the AAC decoder are:

libavcodec/aac.c: In function 'decode_ics':
libavcodec/aac.c:1020: warning: passing argument 6 of
'decode_scalefactors' from incompatible pointer type
libavcodec/aac.c:1020: warning: passing argument 7 of
'decode_scalefactors' from incompatible pointer type
libavcodec/aac.c:1045: warning: passing argument 4 of
'decode_spectrum' from incompatible pointer type
libavcodec/aac.c:1049: warning: passing argument 4 of 'dequant' from
incompatible pointer type
libavcodec/aac.c:1049: warning: passing argument 5 of 'dequant' from
incompatible pointer type
libavcodec/aac.c: In function 'mixdown_and_convert_to_int16':
libavcodec/aac.c:1862: warning: passing argument 2 of
'ac->dsp.float_to_int16_interleave' from incompatible pointer type
libavcodec/aac.c: In function 'decode_ics':
libavcodec/aac.c:1005: warning: 'pulse.num_pulse' may be used
uninitialized in this function
libavcodec/aac.c:1005: warning: 'pulse.start' may be used
uninitialized in this function

The first bunch in decode_ics() are all non-const arrays (band_type,
band_type_run_end and sf) that are being passed into function
arguments that have been declared as being const arrays. Two options
are apparent: cast to const when passing the argument or remove the
const qualifier from the function argument declaration. The latter
would seem the better choice as long as it has no effect on potential
optimisations within the functions in question. Would it have any
adverse effects?

float_to_int16_interleave is because the second argument is float
*output_data[] while the function expects const float ** so again it's
because of a const qualifier. It should be safe to cast to const float
** should it not?

The last two can be initialised as they are not in speed critical code.

Regards,
Rob