[FFmpeg-trac] #2686(avcodec:open): Native AAC encoder collapses at high bitrates on some samples

[FFmpeg]

#2686: Native AAC encoder collapses at high bitrates on some samples
-------------------------------------+-------------------------------------
             Reporter:  Kamedo2      |                    Owner:
                 Type:  defect       |                   Status:  open
             Priority:  normal       |                Component:  avcodec
              Version:  git-master   |               Resolution:
             Keywords:  aac          |               Blocked By:
  regression                         |  Reproduced by developer:  1
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by klaussfreire):

 Replying to [comment:84 Kamedo2]:
 > I don't recommend to ambitiously try to save the HF content above 18kHz
 when there are enough bits. It sounds unstable. Some 1990s early MP3
 encoders had the tactic, but none of them were good. Rather, clean, fixed
 LPF should be applied at all time. Avoid the situation that one can hear
 the 12-20kHz content in some part of the music, and hearing the dull 12kHz
 LPF-like sound in the other part of the music.

 I just want to preserve the HF component of transients. There might be
 better ways of doing that. I guess I'll keep iterating on it. However, I
 believe the way it's being done now works well. If you check, the LP
 cutoff is chosen from the allocation given by psy. Psy contains bit
 reservoir logic, which means it will momentarily increase bits (and
 cutoff) for some difficult transients. Right now, it works wonders for hi-
 hats.

 I will probably have to be stricter about the cutoff, though. As you say,
 when the signal by itself (not by psy's indication, but signal strength
 alone) suddenly jumps in HF content, the result is unpleasant. I think I
 have cleaned up most of those cases, but who knows. It's hard to discern
 those from actual transients.

 > As for
 > {{{
 > pctx->frame_bits   = FFMIN(2560, chan_bitrate * AAC_BLOCK_SIZE_LONG /
 ctx->avctx->sample_rate);
 > }}}
 > do we get more stable results when the number 2560 is lowered?
 > (240kbps is a 'megadose' or 'overkill' bitrate for AAC, so slight
 degradation is not a major problem.)

 If it doesn't limit the ability to increase allocation for transients, it
 might. I'll look into it.

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:86>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker