#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
_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://avcodec.org/mailman/listinfo/ffmpeg-trac
