|Age||Commit message (Collapse)||Author||Files||Lines|
On Classic, IRAM1 (second 128Kb of a total of 256KB available IRAM) is
slower than DRAM. Codecs that actually are using regions of IRAM1 runs
faster when DRAM is used, so IRAM1 is disabled and only IRAM0 remains
enabled: 48KB for core and 80KB for codecs/plugins.
The next test_codec results shows how decode time is decreased:
file boosted unboosted
*.ra ~1.5% ~0.5%
*.mpc ~21% ~4.5%
*.ogg ~0.5% ~0%
nero_he*.m4a ~8% ~1%
nero*.m4a ~25% ~7%
wmapro*.wma ~4.5% ~0%
wma*.wma ~25% ~7%
In addition there is a small power save when IRAM1 HW is disabled.
ffmpeg_bitstream.c is included in libcodec, so there doesn't seem to
be any reason for individual codecs to also compile it (and clobber
any previous copy while they're at it, leading to broken builds)
Several of the problem samples on the tracker use values outside this
range. Trying the larger table doesn't quite seem to fix things, but
its only a small amount of additional memory and looking at ffmpeg,
I think the larger table is correct.
coefficients in their bitstream
No known samples are fixed by this problem, but I haven't tested many.
Backport of ffmpeg revision 26388.
Reviewed-by: Nils Wallménius <email@example.com>
Tested-by: Nils Wallménius <firstname.lastname@example.org>