Assertion failure while converting into EAC3 with bitrate >= 900 kbps: put_bits buffer too small

[ackbc]

EAC3 can go higher than normal AC3 but ffmpeg binary crashes, the upper limit now is around 900 kbps due to the buffer error

How to reproduce:

ffmpeg -i 1.flac -c:a eac3 -b:a 1024k 007.ac3
ffmpeg version git-2020-02-06-343ccfc Copyright (c) 2000-2020 the FFmpeg develop
ers
  built with gcc 9.2.1 (GCC) 20200122
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfi
g --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libb
luray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enab
le-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --e
nable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable
-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 -
-enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enab
le-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --en
able-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-ffnvcode
c --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 -
-enable-avisynth --enable-libopenmpt --enable-amf
  libavutil      56. 39.100 / 56. 39.100
  libavcodec     58. 68.100 / 58. 68.100
  libavformat    58. 38.100 / 58. 38.100
  libavdevice    58.  9.103 / 58.  9.103
  libavfilter     7. 74.100 /  7. 74.100
  libswscale      5.  6.100 /  5.  6.100
  libswresample   3.  6.100 /  3.  6.100
  libpostproc    55.  6.100 / 55.  6.100
Input #0, flac, from '1.flac':
  Metadata:
    VALID_BITS      : 24
    HDCD            : 0
  Duration: 02:36:17.02, start: 0.000000, bitrate: 2626 kb/s
    Stream #0:0: Audio: flac, 48000 Hz, 5.1(side), s32 (24 bit)
Stream mapping:
  Stream #0:0 -> #0:0 (flac (native) -> eac3 (native))
Press [q] to stop, [?] for help
Output #0, ac3, to '007.ac3':
  Metadata:
    VALID_BITS      : 24
    HDCD            : 0
    encoder         : Lavf58.38.100
    Stream #0:0: Audio: eac3, 48000 Hz, 5.1(side), fltp (24 bit), 1024 kb/s
    Metadata:
      encoder         : Lavc58.68.100 eac3
Internal error, put_bits buffer too small
    Last message repeated 56 times
Assertion s->buf_ptr < s->buf_end failed at src/libavcodec/put_bits.h:108

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

[Carl Eugen Hoyos]

If the issue is only reproducible with this particular sample, please provide it.

[ackbc]

hi sample was upped on videolan (with description), file name is 111.flac, 25 Mb

thanks you sir

[Carl Eugen Hoyos]

The crash is a regression since 3ef5de0f19774e2c3dd9b08ba2e8ab7241a4862a

[Balling]

HAHAHA LOL. You can fix it with

ffmpeg -i 111_cut.flac -c:a eac3 -b:a 1024.1k  111_cutout.ac3 

1024 will not work, hahah. So funny.

Anyway, is it bad that mp3 files cannot be reencoded (this error) even with 900k??? Like this one (see next attached).

Also it is very funny I managed to trigger only one warning (without put_bits buffer too small)!!! So apparently there are two bugs...

L:\5777\ffmpeg\bin\ffmpeg.exe -i Z:\Downloads_old\bird.mp3 -c:a eac3 -b:a 883k C:\Users\XXXX\Downloads\111_cut.eac3
ffmpeg version git-2020-02-27-9b22254 Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 9.2.1 (GCC) 20200122
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-ffnvcodec --enable-cuda-llvm --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt --enable-amf
  libavutil      56. 42.100 / 56. 42.100
  libavcodec     58. 73.102 / 58. 73.102
  libavformat    58. 39.101 / 58. 39.101
  libavdevice    58.  9.103 / 58.  9.103
  libavfilter     7. 77.100 /  7. 77.100
  libswscale      5.  6.100 /  5.  6.100
  libswresample   3.  6.100 /  3.  6.100
  libpostproc    55.  6.100 / 55.  6.100
[mp3 @ 000001726d619e40] Skipping 417 bytes of junk at 0.
[mp3 @ 000001726d619e40] Estimating duration from bitrate, this may be inaccurate
Input #0, mp3, from 'Z:\Downloads_old\bird.mp3':
  Duration: 00:01:10.53, start: 0.000000, bitrate: 128 kb/s
    Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 128 kb/s
File 'C:\Users\xxxx\Downloads\111_cut.eac3' already exists. Overwrite? [y/N] y
Stream mapping:
  Stream #0:0 -> #0:0 (mp3 (mp3float) -> eac3 (native))
Press [q] to stop, [?] for help
Output #0, eac3, to 'C:\Users\xxxx\Downloads\111_cut.eac3':
  Metadata:
    encoder         : Lavf58.39.101
    Stream #0:0: Audio: eac3, 44100 Hz, stereo, fltp, 883 kb/s
    Metadata:
      encoder         : Lavc58.73.102 eac3
Assertion s->buf_ptr < s->buf_end failed at src/libavcodec/put_bits.h:108

[Balling]

Hmm, I thought switch to 64 bit underlying buffers will fix this issue. Nope.

[Balling]

There was this overflow: ​https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210325154956.2405162-12-andreas.rheinhardt@gmail.com/

Just wonderful.

[Carl Eugen Hoyos]

Replying to Balling:

There was this overflow: ​https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210325154956.2405162-12-andreas.rheinhardt@gmail.com/

Why are you mentioning this patch in this ticket?

[Balling]

Replying to cehoyos:

Replying to Balling:

There was this overflow: ​https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210325154956.2405162-12-andreas.rheinhardt@gmail.com/

Why are you mentioning this patch in this ticket?

Is not s->buf_ptr >= s->buf_end an overflow?

[Carl Eugen Hoyos]

Replying to Balling:

Replying to cehoyos:

Replying to Balling:

There was this overflow: ​https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210325154956.2405162-12-andreas.rheinhardt@gmail.com/

Why are you mentioning this patch in this ticket?

Is not s->buf_ptr >= s->buf_end an overflow?

I believe an integer overflow can happen if you add or subtract a signed integer, no addition or subtraction happens in this condition.

[mkver]

This is not ticket #8350 in which case the put_bits buffer is so huge that the multiplication in "s->size_in_bits = 8 * buffer_size;" (that's the line that is removed in this patch) overflows a typical 32bit int. A pointer comparison can never overflow (but if the pointers aren't comparable, the comparison is undefined behaviour).
Regarding this bug: ac3_output_frame() in libavcodec/ac3enc.c sets the size of the put_bits buffer to 3840, even when the actually allocated packet is smaller than this. That is definitely wrong.

[Balling]

Replying to mkver:

This is not ticket #8350

Just to clarify, I did not mix the tickets up, I thought this ticket may be related. As I said the workaround is to have floating bitrate. What that means (and as you said above about 3840) is that something is broken about integer bitrate. Maybe an overflow. Okay? And what I meant about that check above (two of them, there are two bugs here) is that it can be an overflow check in some way. But it is nice to see you fixed them in new patch series on mailing list. Thanks.

[mkver]

Fixed in 968c158abde36ebb7520706a69eebe3e8eacbd81.

[Balling]

The original file is still not fixed, i.e. it produces now a corrupted file (can attach?).

1024.1k still fixes it, D:)

My sample is fixed though.
P.S. The sample does play in Pot Player though. It just does not play in ffplay, et al. Maybe it is just due to how small 111_cut.flac​ is?

[mkver]

Seems to be an unrelated probing bug. Forcing the input format with -f ac3 fixes it.

[Balling]

Replying to mkver:

Seems to be an unrelated probing bug. Forcing the input format with -f ac3 fixes it.

Do I need to open a new bug?