Koen Vos authored 13 years ago and Jean-Marc Valin committed 13 years ago

Also some comment/warning fixes

Only encoder changes were necessary because this uses the same
"redundant frames" mechanism as SILK<->CELT switching.
This also fixes a regression introduced in 78291b27 that was
causing the encoder to go back and forth between bandwidths when
SILK wasn't ready to change.

Fix stack corruption with high rate SILK encoding added by the recent CBR changes and enable -fstack-protector-all on gcc autotools builds.

This fixes an overflow that was caused by having a huge gain

This is achieved by running the encoding process in a loop and
padding when we don't reach the exact rate. It also implements
VBR-with-cap, which means we no longer need to artificially decrease
the SILK bandwidth when it's close to the cap.

Correct encoder/decoder state mismatch and spurious state resetting in the encoder when side is reset.

Patch from Tim which corrects a glitch during mode switching tests.

Timothy B. Terriberry authored 13 years ago and Gregory Maxwell committed 13 years ago

If there is activity in a regular, side SILK frame, then it must
 be coded, so we don't need to send a mid-only flag.

Timothy B. Terriberry authored 13 years ago and Jean-Marc Valin committed 13 years ago

Neither the encoder nor decoder were incrementing the side-channel
 index for a mid-only frame.
Unfortunately, they used that index to index the VAD flags and LBRR
 flags.
This made the VAD flags for the side channel particularly useless,
 as you couldn't tell which frame a flag belonged to without
 decoding most of the packet.
It also desynched the LBRR information, as look at the wrong LBRR
 flags to decide when it had to code a mid-only flag.
If some frames were skipped in the side channel, then the last few
 VAD flags and LBRR flags would be garbage, but still get encoded.

This patch fixes this by continuing to increment nFramesDecoded or
 nFramesEncoded, even when skipping a frame in the side channel.
This makes the side-channel VAD and LBRR flags correspond to the
 correct time periods for frames greater than 20 ms.
It also fixes a bug where if DTX was not used on the packet where
 the side channel got turned off, it would never get used again
 until the encoder attempted to encode something in the side
 channel again.

Timothy B. Terriberry authored 13 years ago and Jean-Marc Valin committed 13 years ago

b24e5746 introduced changes to LastGainIndex which broke
 conditional coding for side frames after a mid-only frame (i.e.,
 in a 60 ms frame where the side is coded, not coded, then coded
 again).
These rules were a mess in general, however, because the side
 channel state kept a different nFramesDecoded count from the mid
 channel state, and had no way to tell if the prior side frame was
 coded.

This patch attempts to rationalize them by moving the conditional
 coding decision up to the top level, where all this information is
 available.
The first coded side frame after an uncoded side frame now always
 uses independent coding.
If such a frame is also not the first side frame in an Opus frame,
 then it doesn't include an LTP scaling parameter (because the LTP
 state is well-defined).

Only one of the two required checks in the encoder were updated. Thanks to
Tim for tracking down the actual cause of the mismatch.

These were caused by not prefilling the hybrid CELT state

Timothy B. Terriberry authored 13 years ago and Jean-Marc Valin committed 13 years ago

A number of fixes and additions, including
* Ensure all usage of the word "mode" refer only to the choice of
   SILK/hybrid/CELT, not audio bandwidth, frame size, channel count,
   or anything else.
  There's still a bunch of usage of "mode" in CELT to refer to
   things in the CELTMode struct (e.g., band layout, etc.).
* Document the LSF reordering for silk_NLSF2A_find_poly().
* Document the DC response check during LSF stabilization.
* Fix the excitation scaling to give decoded SILK output in the
   range -1.0...1.0.
* Rewrite the mode-switching section.
  Ironically the title of the section still implies "mode" means
   than just SILK/hybrid/CELT, but I couldn't come up with a
   better one.
* Minor clean-ups to the acknowledgements.

Koen Vos authored 13 years ago and Jean-Marc Valin committed 13 years ago

Input that caused the problem was:
a_Q16[] = [129763 -49346 -42032 5488 28014 -1549 -2384 -8568
3154 -5104 -1605 6291 11861 -1843 -17715 7361]

The energy "sliding window" was using double accumulation with
float multiplications. This forces the multiplications to be
double as well.

The previous commit introduced some cross-talk for the case of SILK
with one channel muted.

- There was a bug where the decoder resampler was not properly initialized
when fs_kHz == API_fs_kHz. In that case the resampler would continue to
upsample, and the output was corrupt.

- The delay value in the decoder was taken from the state before it was
potentially updated. This caused the decoder to apply the new dalay value one
frame late

- The encoder and decoder states are now updated more consistently, when
the sampling rate changes (pesq liked these changes)

- Properly resetting the side channel encoder and decoder for the first
frame with side coding active again

- Faster updating the "ratio" value in the LR_to_MS() code for large
prediction values means that for certain extreme/artificial input
signals the output looks better