[FFmpeg-devel] [PATCH] HE-AACv1 second revision

[Vitor Sessak]

Michael Niedermayer wrote:
> On Tue, Feb 09, 2010 at 10:03:07AM -0500, Alex Converse wrote:
>> On Mon, Feb 8, 2010 at 9:16 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
>>> On Sat, Jan 30, 2010 at 05:33:00PM -0500, Alex Converse wrote:
>>>> On Sat, Jan 30, 2010 at 5:32 PM, Alex Converse <alex.converse at gmail.com> wrote:
>>>>> Notes:
>>>>> *There are still several lroundf() calls that take all integer inputs.
>>>>> If anyone has advice on how to do them in an integer only fashion. I
>>>>> would love to hear it.
>>> could you tell me what range the input values to the remaining 4 equations
>>> have?
>> +        num_bands_0 = lrintf(half_bands * log2f(sbr->k[1] / (float)sbr->k[0])) << 1;
>> half_bands = {4, 5, 6}
>> k[1] = {1..64}
>> k[0] = {1..32}
>> k[1] / k[0] <= 2.2449f
>> k[1] - k[0] <= 48
> 
> (ilog2(725*ipow(b, h)/ipow(a, h))-9)<<1;

I don't know if Michael will like my idea, but the closest (in 
precision) argument to lrintf() to a half integer in this case is

num_bands = 6, k[0] = 11, k[1] = 37,
half_bands * log2f(sbr->k[1] / (float)sbr->k[0]) = -10.500130

which would need the floating-point result to be correct up to the 16th 
bit, which I find should be true for any system not broken beyond 
uselessness. So, in this case, I think using lrintf() is safe (in the 
sense that any valid pair compiler/cpu should give the right value, no 
matter if it works in base 7 internally). To be extra-safe one could use 
double.

-Vitor