On 08/09/2011 07:02 AM, Justin Ruggles wrote:
> On 08/08/2011 07:44 PM, Ronald S. Bultje wrote:
>
>> Hi,
>>
>> On Sun, Aug 7, 2011 at 4:29 PM, Justin Ruggles <[email protected]>
>> wrote:
>>> ---
>>> libavcodec/ac3enc_template.c | 3 +--
>>> 1 files changed, 1 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/libavcodec/ac3enc_template.c b/libavcodec/ac3enc_template.c
>>> index f913811..74f4b21 100644
>>> --- a/libavcodec/ac3enc_template.c
>>> +++ b/libavcodec/ac3enc_template.c
>>> @@ -126,7 +126,7 @@ static inline float calc_cpl_coord(float energy_ch,
>>> float energy_cpl)
>>> float coord = 0.125;
>>> if (energy_cpl > 0)
>>> coord *= sqrtf(energy_ch / energy_cpl);
>>> - return coord;
>>> + return FFMIN(coord, COEF_MAX);
>>> }
>>>
>>>
>>> @@ -291,7 +291,6 @@ static void apply_channel_coupling(AC3EncodeContext *s)
>>> if (!block->cpl_in_use)
>>> continue;
>>>
>>> - clip_coefficients(&s->dsp, cpl_coords[blk][1], s->fbw_channels *
>>> 16);
>>
>> A "why" would be useful here, since you recently included DSP clipping
>> because it was faster. Was it not faster in this case? If that's the
>> case, please amend log msg && patch ok. If it's something else, could
>> you elaborate?
>
>
> It's better to have the final clipped coordinate values when determining
> when to send new coordinates, so it needs to be done right away rather
> than at the end.
>
> I might be able to put the DSP clipping in both places though. I'll
> revisit this patch and test to see if that's any faster.
It's faster to clip directly in calc_cpl_coord().
Athlon64 benchmarks, in cycles, to calculate & clip coordinates for 1
block for all 5 channels.
fixed: 680 clip_coefficients
451 calc_cpl_coord
float: 332 clip_coefficients
207 calc_cpl_coord
I'll amend the commit message.
Thanks,
Justin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
