[FFmpeg-devel] [PATCH 0/2] Remove float_to_int16 add bias hack

[Måns Rullgård]

Justin Ruggles <justin.ruggles at gmail.com> writes:

> I'm not convinced that the hack in DSPContxt.float_to_int16 where
> the C version has a different scale and bias than the SIMD versions
> is really needed.  The addition still has to be done somewhere.
> In most cases this seems to be in vector_fmul_window(), and in other
> cases it's just a completely separate loop over the samples to add
> the bias that would otherwise not be needed.  For the
> vector_fmul_window() cases, the add bias in that function is ONLY
> there because of the C version of float_to_int16.  And if a system
> has to use a C version of float_to_int16, likely it also has to use
> the C version of vector_fmul_window() and there is no net gain.

Agreed.  If anyone believes there is reason to keep this hack, please
provide benchmarks.

> Anyway, here is a patch to make float_to_int16() always take input
> in the range [-32768.0,32767.0], removing the need for the add bias.
> The scaling could still be useful in the future though if those
> decoders are modified to give float output instead of int16. It
> would be nice to still have the flexibility to change the scale of
> the output float samples per user request without additional
> overhead.
>
> This patch does not address the 3 asm functions that will no longer
> need the bias parameter.  I just don't feel comfortable enough
> with modifying the ARM versions myself.
> SynthFilterContext.synth_filter_float()
> DCADSPContext.lfe_fir()
> DSPContext.vector_fmul_window()

That's fine.  I'll take care of the ARM versions.  Unfortunately, due
to ordering of function arguments, we must remove it from all the
implementations at the same time.  That's not blocking this patch
though.

-- 
M?ns Rullg?rd
mans at mansr.com