Complexity numbers for IVAS EVS mode are extremely high for VBR and rate switching modes
When measuring complexity for the EVS path of the IVAS framework, there is unexpectedly high computational complexity for the VBR mode (5.9kbps) and some rate switching modes. E.g. for 5.9kbps VBR, this is reported:
Instruction Type Analysis (for worst case frame number 9394):
Adds: 277162.3
Absolutes: 61844.5
Multiplies: 183425.1
MACs: 265134.0
Moves: 181843.5
Stores: 0.0
Logicals: 192.0
Shifts: 59615.9
Branches: 31603.4
Divisions: 10692.5
Square Root: 378.6
Trans: 185986.7
Func Call: 3856.0
Loop Init: 9056.3
Indirect Addr: 455828.1
Pointer Init: 0.0
Extra condit.: 0.0
Exponential: 0.0
Logarithm: 0.0
All other op.: 0.0
Weighted MOPS Analysis ( WMOPS boost factor 1.10 ):
|------ SELF ------| |--- CUMULATIVE ---|
routine calls min max avg min max avg
--------------- ------ ------ ------ ------ ------ ------ ------
evs_enc 1.00 0.410 0.427 0.420 17.120 381.746 35.402
pre_proc 1.00 12.547 13.412 13.114 12.547 13.412 13.114
acelp_core_enc 1.00 3.815 368.279 21.786 3.815 368.279 21.786
BWE_encoding 1.00 0.043 0.083 0.081 0.043 0.083 0.081
--------------- ------ ------ ------ ------
total 10336.00 17.136 381.763 35.419
I ran the same file through (actual) EVS with instrumentation and there the numbers are much lower, so it is not a bug with the EVS mode, but a problem with our implementation. BE is apparently not affected.
As the -stereo_dmx_evs
mode also uses the EVS path for encoding the downmix signal, this mode is also affected by this bug. One can see it in the numbers displayed here.
How to reproduce
Instrument the code and feed the ltv48_MONO.wav
signal from the testfiles repo to the encoder (you need to resample it to 16kHz first):
IVAS_cod -dtx -max_band WB 5900 16 ltv48_MONO_16.wav bit
Alternatively, use the python scripts:
scripts/IvasBuildAndRunChecks.py --check COMPLEXITY -m mono_b05_9_dtx_wb_vbr -p ci_linux_ltv.json
cat COMPLEXITY/logs/ltv48_MONO_mono_b05_9_dtx_wb_vbr.enc.txt