[FFmpeg-devel] [RFC] ac3dec: use dsputil.clear_block

[Måns Rullgård]

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

> M?ns Rullg?rd wrote:
>
>> Justin Ruggles <justin.ruggles at gmail.com> writes:
>> 
>>> Reimar D?ffinger wrote:
>>>
>>>> On Wed, Jan 13, 2010 at 11:42:27PM +0100, Michael Niedermayer wrote:
>>>>> On Wed, Jan 13, 2010 at 09:46:17PM +0100, Reimar D?ffinger wrote:
>>>>>> Hello,
>>>>>> this gives an overall speedup of about 1.1 % on Intel Atom with my sample.
>>>>>> Testing with other CPUs and samples heavily welcome, I suspect a
>>>>>> slowdown may be possible, beside it being a bit ugly.
>>>>> what happens with these coeffs afterwards?
>>>>> is it
>>>>> s->dsp.int32_to_float_fmul_scalar(s->transform_coeffs[ch], s->fixed_coeffs[ch], gain, 256);
>>>>> ?
>>>>> if so maybe that could be changed to not touch the supposed to be zero
>>>>> coeffs?
>>>> I had that idea as well, but I have to admit I do not know, nor if
>>>> I will have the time to understand the code well enough to know :-)
>>> Yes the only time they're used is when they're converted to float.
>> 
>> What about doing the float conversion on the fly instead of as a
>> separate pass?
>
> The only place to do it on-the-fly would be when decoding the mantissas,
> which would be the natural place to do that anyway.  Then the coupling
> coordinates would also need to be floating-point, as well as the stereo
> rematrixing calculations.  Then the headroom and dynamic range scaling
> would still need to be applied, which is now done during int-to-float
> conversion.  So I doubt the change would be any faster, but it might be
> worth a try.

I didn't realise there was that much processing going on.

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