[FFmpeg-devel] [PATCH 2/2] libavcodec: Implementation of AC3 fixed point decoder

[Christophe Gisquet]

2013/4/12 Nedeljko Babic <Nedeljko.Babic at imgtec.com>:
> AS for FP DSP functions, adding additional parameter that hold info about
> used format would increase their usability, but it would also add some overhead
> to functions (for example for calculating rounding) and it is maybe overkill at
> this moment (since there is no code that uses other format).

My goal was rather to be able to do something like:

if( fp_dsp->dbits = 12 ) {
  if( some_arch) {
    s->round = ff_round_fp12_some_arch;
    s->fmul_scalar = ff_fmul_scalar_fp12_some_arch;
  }
}

if( fp_dsp->dbits = 16 ) {
  if( some_arch) {
    s->round = ff_round_fp16_some_arch;
    s->fmul_scalar = ff_fmul_scalar_fp16_some_arch;
  }
}

The AC3 FP code then sets or ask to initialize the FP DSP context with
dbits = 12

Otherwise, the DSP context would get filled with every FP format needed:
s->fmul_scalar_fp16(...)
s->fmul_scalar_fp12(...)

But it seems there are cases where both are needed, hence the question
on the 15 bits.

>>2) Some places use it seems 15bits of decimal precision. Why is that?
>>
>
> We are using different precision in accordance with the value range that we need in
> particular part of the algorithm.

OK, so this makes it a requirement.

>>3) Speed-wise, how does it compare to the float version on your target device?
>>You'd probably need to write optimized dsp functions first, I guess
>>
>
> When compairing optimized floating point version and fixed point version (both optimized
> for our platform) fixed point code is 25% - 40% faster on our test streams (this is
> ofcourse for current version of optimized code)

Nice, the numbers make the FP version attractive.

>>4) Third, quality-wise, how do you validate the quality?
>>Something like outputting both float and FP decoders to 16bits signed,
>>and computing the MSE/max error?
>>Having some figures could be interesting.
>>
>
> We are comparing wav files generated by fixed and floating point decoders.
> Max. difference on our test streams is 4 LSB bits when downsampling and 1 LSB bit
> without downsampling.

What do you call "downsampling"? Output to s16 or s32?

>>5) Are there still some non-deterministic parts, like still using
>>floats, besides the precomputed tables?
>>ie, can the output be checked for exact matching via MD5?
>>If one is to write optimized dsp functions besides yours, this could
>>help check the validity of the optimizations.
>>
>
> There should be no non-deterministic parts left, so it should be possible to use
> tool for checking exact matching.

I guess this, like the FP17.15 parts, depends on the optimizations one
can achieve.

I'm myself not at all versed in fate test writing, but was wondering
what impact this FP stuff could have.

Thanks,
--
Christophe