Playback errors when converting PCM to AAC

[David Johansen]

Summary of the bug: Quicktime and Safari runs into issues when playing back a PCM file that has been converted to AAC
How to reproduce:
Original file: ​https://drive.google.com/file/d/1-vTqNyUdZzGf7ilzCLITXfwn9IYWkVvu/view?usp=sharing
Result of conversion: ​https://drive.google.com/file/d/1-0VvNj2PVoqVwdEygqiIdU2FwHQzUjU7/view?usp=sharing

% ffmpeg -hide_banner -i audio_test_long.flv -vn -acodec aac converted.mp4

ffmpeg version 5.1.2 Copyright (c) 2000-2022 the FFmpeg developers
  built with gcc 10 (Debian 10.2.1-6)
  configuration: --disable-debug --disable-doc --disable-ffplay --enable-gpl --enable-libx264 --enable-libx265 --enable-librsvg --enable-openssl --enable-nonfree --extra-libs=-ldl --extra-libs=-lpthread
  libavutil      57. 28.100 / 57. 28.100
  libavcodec     59. 37.100 / 59. 37.100
  libavformat    59. 27.100 / 59. 27.100
  libavdevice    59.  7.100 / 59.  7.100
  libavfilter     8. 44.100 /  8. 44.100
  libswscale      6.  7.100 /  6.  7.100
  libswresample   4.  7.100 /  4.  7.100
  libpostproc    56.  6.100 / 56.  6.100

Debian Bullseye

[David Johansen]

Log from converting PCM file to AAC

[quinkblack]

You can set audio bitrate to workaround this issue:

ffmpeg -i test.flv -vn -c:a aac -b:a 20k out.mp4

I don't know what Apple messed up.

[David Johansen]

That does playback correctly and the size of the output file is 174449 and then if I do -b:a 40k the size of the output is 306617, but if I do -b:a 50k, then it's the same size as the default output (308820) and has the same problem.

So is there a way to try and identify what's causing the problem? Because it feels like there's a very small difference between the default output and specifying -b:a 40k.

[David Johansen]

I'm directly using pyav and noticed that this problem ​doesn't happen with 8.1.0, so I tried ffmpeg 4.3.5 since that's the version that it uses for it's wheels, and this problem doesn't happen, so it appears that this issue was introduced in the 4.4 release.

[David Johansen]

It appears the issue is with the twoloop encoder and switching to fast avoids the problem when running with ffmpeg 5.1.2 but the warning about bit rate still happens unless a value is specified:
Too many bits 16384.000000 > 6144 per frame requested, clamping to max

[Balling]

and switching to fast avoids

Fast is unusable, low quality and bad bugs.

[David Johansen]

Replying to Balling:

and switching to fast avoids

Fast is unusable, low quality and bad bugs.

Any recommendations for other solutions or how to fix the issue with the twoloop coder?

I've tested with 6.0 and the latest code from the repo and it's still happening. The one different I noticed is that the warning changed slightly with the latest code (N-112445-gf31d0f1141):
[aac @ 0x5586470ea580] Too many bits 8832.000000 > 6144 per frame requested, clamping to max