Wrong decoding of framing in TCX10 frames after lost frames possible (180)

In TCX10 frames, the two subframes are further decomposed into even smaller blocks (TCX5) depending on the current and previous windowing. Possible configurations are:

• 1st block TCX5, 2nd block TCX10
• 1st block TCX10, 2nd block
• both blocks TCX5

In the code, the decision about the framing in the decoder is done using the variables st->hTcxCfg->tcx_last_overlap_mode and st->hTcxCfg->tcx_curr_overlap_mode. Only the current overlap mode is written in the bitstream. After decoding a frame, the last overlap mode is updated with the current overlap mode.

When a frame is lost and the next frame is TCX10, however, the last overlap mode is lost. This can lead to wrong framing decisions (assuming TCX10 when decoding data that is actually TCX5 or vice versa) and thus to incorrectly decoded spectral data. The solution for this is to also write the last overlap mode in the bitstream for TCX10 frames. A fix is already in the code under inactive FIX_IVAS_180_PLC_SIGNAL_LAST_OVLP_IN_TCX10.

This bug is not specific to stereo TCX, but also exists in EVS mono. The fix only covers IVAS modes and leaves EVS unchanged for now.

An outstanding fix before activation is to again write last_core for TCX10 frames which was removed to save bits. This can, however in rare conditions lead to crashe so should be undone.