[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):

 Attached the current WIP.

 An explanation of what caused the bug for high q values: there was a bug
 in psy's threshold reduction for hole avoidance. When a second pass was
 needed, it would accumulate errors due to a simple typo (reduction +=
 instead of reduction =).

 I don't have the 3GPP spec to check, but I just noticed the code made no
 sense with the +=, but did with =.

 Then there's the ESC_BT thing.

 I think most serious anomalies have been fixed in this bug, I haven't had
 time to properly test CBR, but it seems to mostly work now. That was very
 subtle bit reservoir a bug on my "lookahead" patch that didn't surface
 until I fixed psy.

 Anyway, I still would like to make VBR achieve lower bitrates without
 having to resort to LP filtering. I somehow sense it should be possible.
 In any case, I made CBR also use the same scalefactor-band-based LP
 filtering to remove the need for the butterworth that didn't save many
 bits anyway, and now it responds to the -cutoff argument, so if you don't
 like the default cutoff you can override yourself. It seemed worth
 parameterizing since I've found some sources that sound better at low bit
 rates with higher cutoffs, and some that don't. So it's source-dependent.

 Anyway, enjoy the patch, I'm not sure I'll have time to work on a more
 permanent (one that I'd push to trunk) one till next weekend.

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