[FFmpeg-devel] [PATCH] atrac decoder
Wed Aug 12 22:13:51 CEST 2009
M?ns Rullg?rd wrote:
> Benjamin Larsson <banan at ludd.ltu.se> writes:
>> Michael Niedermayer wrote:
>>>> Well as vector_fmul_window is defined now you need to use the complete
>>> and when window is 0 or 1 some other function could be used, besides
>>> is vector_fmul_window + half_imdct slower than the cutrrent code?
>> I did a test run that used one call to imdct_half and on call to
>> vector_fmul_window per time the imdct function was invoked (ie it didn't
>> decode properly it was just the same amount of calls). I got these numbers:
>> 192195 dezicycles in mdct, 127 runs, 1 skips
>> 190436 dezicycles in mdct, 255 runs, 1 skips
>> 189578 dezicycles in mdct, 511 runs, 1 skips
>> 190527 dezicycles in mdct, 1021 runs, 3 skips
>> 190002 dezicycles in mdct, 2043 runs, 5 skips
>> 188916 dezicycles in mdct, 4086 runs, 10 skips
>> 188563 dezicycles in mdct, 8173 runs, 19 skips/s
>> 162004 dezicycles in mdct, 127 runs, 1 skips
>> 161286 dezicycles in mdct, 255 runs, 1 skips
>> 163959 dezicycles in mdct, 511 runs, 1 skips
>> 164064 dezicycles in mdct, 1022 runs, 2 skips
>> 163556 dezicycles in mdct, 2043 runs, 5 skips
>> 163445 dezicycles in mdct, 4088 runs, 8 skipss/s
>> 163775 dezicycles in mdct, 8180 runs, 12 skips/s
>> Is that difference worth the extra memory needed for the mdct windows ?
> That's a significant speedup. How much memory are we talking about?
sizeof(float)*(128+256) bytes + some code to build the tables. And to
reiterate the code using mdct_half and fmul_window didn't produce valid
output, I just added the same amount of calls that would be needed for
real output. So the values should be fairly accurate but would differ
from a working implementation.
More information about the ffmpeg-devel