On 08/08/2011 07:50 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Aug 7, 2011 at 4:29 PM, Justin Ruggles <[email protected]>
> wrote:
>> ---
>> libavcodec/ac3enc.h | 2 ++
>> libavcodec/ac3enc_fixed.c | 1 +
>> libavcodec/ac3enc_template.c | 24 ++++++++++++++++++------
>> 3 files changed, 21 insertions(+), 6 deletions(-)
> [..]
>> -static inline float calc_cpl_coord(float energy_ch, float energy_cpl)
>> +static inline CoefType calc_cpl_coord(CoefSumType energy_ch, CoefSumType
>> energy_cpl)
>> {
>> +#if CONFIG_AC3ENC_FLOAT
>> float coord = 0.125;
>> if (energy_cpl > 0)
>> coord *= sqrtf(energy_ch / energy_cpl);
>> return FFMIN(coord, COEF_MAX);
>> +#else
>> + return 1048576;
>> +#endif
>
> That doesn't look the same at all?
This patch just gets the fixed-point path working. Returning 1/16 in
fixed-point makes the coupling bandwidth range the correct amplitude but
it's mono. It sounds fine except for that. Patch 9/10 implements the
channel-weighted coordinates. Alternatively, I could rearrange the
patches and squash 6 and 9.
>> + LOCAL_ALIGNED_16(CoefType, cpl_coords, [AC3_MAX_BLOCKS],
>> [AC3_MAX_CHANNELS][16]);
>> #if CONFIG_AC3ENC_FLOAT
>> - LOCAL_ALIGNED_16(float, cpl_coords, [AC3_MAX_BLOCKS],
>> [AC3_MAX_CHANNELS][16]);
>> LOCAL_ALIGNED_16(int32_t, fixed_cpl_coords, [AC3_MAX_BLOCKS],
>> [AC3_MAX_CHANNELS][16]);
>> +#else
>> +#define fixed_cpl_coords cpl_coords
>> +#endif
>
> Ehw. That is a little icky and will lead to a hard-to-debug conflict
> later on. I'm wondering if you could use something like a struct
> (float encoder) vs union (fixed-point encoder) here instead, i.e.:
>
> #if CONFIG_AC3ENC_FLOAT
> struct {
> #else
> union {
> #endif
> LOCAL_ALIGNED_16(CoefType, cpl_coords, [AC3_MAX_BLOCKS],
> [AC3_MAX_CHANNELS][16]);
> LOCAL_ALIGNED_16(int32_t, fixed_cpl_coords, [AC3_MAX_BLOCKS],
> [AC3_MAX_CHANNELS][16]);
> } someprefix;
Yeah, I know it's pretty ugly. I didn't think of a union/struct combo.
It also seems out-of-the-ordinary, but at least it's C and not
pre-processor trickery. I'll give it a try.
Thanks,
Justin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
