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

 So, I attached a patch that moves in the right direction (I think).

 Most of the worse-performing samples, I noticed, had to do with hole
 avoidance being quickly violated when using low bit rates. So I re-did
 twoloop's RD improvement step to better respect hole avoidance, to be
 asymmetric in its scale manipulation (ie: to avoid adding all 1 or all 2,
 which would be quickly undone by the bitrate adjustment step), and
 everything seemed to work a lot better.

 However, on the "asymmetric" little word, there's a huge hack involved. I
 wouldn't want to waste your time without a warning: this hack can most
 assuredly be improved. But I don't think I'll waste time improving a hack,
 since the real solution is to implement a dynamic programming coder, which
 I intend to do in the future. So while hackish and probably suboptimal,
 I'll probably leave it as-is since it works well enough.

 I haven't tested VBR much. From what I tested, it seems mostly unharmed,
 but it still needs a better calibrated cutoff. That will take time (lets
 say it'll be v6).

 So, this patch should be good enough for ABR. VBR will need a v6, and some
 day (time permitting) I'll post '''the''' patch with the dynamic coder.

 I couldn't quite match FDK performance, but I suspect there's two reasons
 for this. First, M/S coding isn't as good as it should be. And 2, FDK
 probably uses a dynamic coder. So I think we'll catch FDK with the dynamic
 coder (which can also do the M/S part, so it'll fix both with one shot).

 However, I tested most of the samples in your session, and '''they've all
 improved'''. Some more than others, of course. So, if not all the samples,
 you might want to retest the worst offenders.

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