FFMPEG Audio decoding fails on audio packet (works using libfdk)
|Reported by:||ray||Owned by:|
|Blocking:||Reproduced by developer:||no|
|Analyzed by developer:||no|
Summary of the bug:
We use the FFMPEG default aac encoder to produce a 320k HLS stream:
ffmpeg -i graves-master-2.mp3 -ar 48000 -b:a 320k -hls_time 6 -hls_list_size 0 -hls_base_url segments/ -hls_segment_filename segments/segment%03d.ts -vn out.m3u8
On several occasions, we have observed behavior in Chrome where audio stops playing (PIPELINE DECODE ERROR) e.g.
(1) Visit https://audius.co/wearegraves/digital-mirage-full-set-60702
(2) Scrub to 13:20
(3) At 13:24, the audio stops
When inspecting the segment that causes issues, we observe error in spectral data, ESC overflow. This same behavior *does not* occur when using the libfdk aac.
How to reproduce:
ffmpeg -i ~/Downloads/QmUR6MeguuuvstqeK5q4q2EoroWQiY5d9bt1QqrzMEpQyd -vn -f wav -y /dev/null I see Input #0, mpegts, from '/Users/raymondjacobson/Downloads/QmUR6MeguuuvstqeK5q4q2EoroWQiY5d9bt1QqrzMEpQyd': Duration: 00:00:05.97, start: 805.410667, bitrate: 348 kb/s Program 1 Metadata: service_name : ekali set 9 shorter service_provider: FFmpeg Stream #0:0[0x100]: Audio: aac (LC) ( / 0x000F), 48000 Hz, stereo, fltp, 319 kb/s Stream mapping: Stream #0:0 -> #0:0 (aac (native) -> pcm_s16le (native)) Press [q] to stop, [?] for help Output #0, wav, to '/dev/null': Metadata: ISFT : Lavf58.42.100 Stream #0:0: Audio: pcm_s16le ( / 0x0001), 48000 Hz, stereo, s16, 1536 kb/s Metadata: encoder : Lavc58.80.100 pcm_s16le [aac @ 0x7fb0d000c400] error in spectral data, ESC overflow Error while decoding stream #0:0: Invalid data found when processing input size= 1120kB time=00:00:05.99 bitrate=1530.6kbits/s speed= 504x video:0kB audio:1120kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.006801%
Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.
Attached is the segment that causes issues.
Here is a link to the "master" audio file: https://drive.google.com/file/d/1FziM3tAXvRzjA8XmxGUEan4Z0dtEPYez/view?usp=sharing
I was sent to the FFMPEG team from the Chromium team as they don't take ownership for this issue despite Firefox and Safari being able to handle the output correctly.