On 18.04.2015 04:40, Michael Niedermayer wrote:
> On Sat, Apr 18, 2015 at 12:55:08AM +0200, Andreas Cadhalpun wrote:
>> The problem is that minath is not the minimum, only close:
>> minath = ath(3410, ATH_ADD) = -5.24237967
>> ath(3407, ATH_ADD) = -5.24241638
>
> the exact location of the minimum depends on teh "add" value
> its around 3410 for add=0 and around 3407 for add=4
True.
> for fun, 3407.080774800152 is even closer than 3407 for add=4
Yes, but the ath function calculates with floats and thus is
inaccurate enough that it doesn't matter if the input is 3407
or 3407.1.
> but the "add" parameter should probably be user selectable
Currently ATH_ADD is a #define, but if that was made user selectable,
one could approximate the position of the minimum:
minath = ath(3410 - 0.733 * ATH_ADD, ATH_ADD)
> also if you want to prevent coeffs[].ath from becoming negative then
That isn't strictly required, because 0 is a valid value and is just
as bad as a negative one.
But I assume the model works better, if it uses something closer to the
minimum of the ath function.
> you have to check coeffs[].ath, as
> float rounding and optimizations can differ between platforms
>
> you cannot even know for sure that
> ath(3407, ATH_ADD) == ath(i, ATH_ADD) when i == 3407
>
> the value calculated with a constant can be calculated at build time
> but in the loop the code could have been optimized/factored/whatever
> by the compiler and produce different values as a result
Best regards,
Andreas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
