AC3 decoder fault after long running transcoding

[DeHackEd]

Summary of the bug:
I am running a video transcoder on a TV channel (multicast source) that runs pretty much 24/7. After a long period of time (eg: days or weeks) the AC3 decoder will hit some kind of error (I do not have the error at this time) and enter a permanent fault state. In this state the audio decoded is simply a single long tone even though the source material has recovered from whatever error it encountered in the first place.

While in this state ffmpeg produces the same error non-stop. The output AAC audio has decoder errors as well, more on that later. I have seen two different errors so far:

[ac3 @ 0x334b7e0] new coupling strategy must be present in block 0
[ac3 @ 0x334b7e0] error decoding the audio block
[ac3 @ 0x334b7e0] new coupling strategy must be present in block 0
[ac3 @ 0x334b7e0] error decoding the audio block

OR

[ac3 @ 0x24b9360] exponent -1 is out-of-range
[ac3 @ 0x24b9360] error decoding the audio block
[ac3 @ 0x24b9360] exponent -1 is out-of-range
[ac3 @ 0x24b9360] error decoding the audio block

(the exponent number does vary)

The output file produces errors from the AAC encoded audio:

[ffmpeg/audio] aac: element type mismatch 1 != 0
[ffmpeg/audio] aac: element type mismatch 1 != 0
[ffmpeg/audio] aac: element type mismatch 1 != 0
[ffmpeg/audio] aac: element type mismatch 1 != 0
[ffmpeg/audio] aac: element type mismatch 1 != 0
[ffmpeg/audio] aac: element type mismatch 1 != 0

Restarting ffmpeg will return it to normal operation consistently.

ffprobe of the source stream:

Input #0, mpegts, from 'udp://239.x.y.z:1234':

Duration: N/A, start: 18332.569233, bitrate: N/A
Program 1521

Stream #0:0[0x81e](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 384 kb/s
Stream #0:1[0x81f]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc

How to reproduce:

% ffmpeg -nostdin -loglevel warning -i udp://239.x.y.z:1234 -c:a libfdk_aac -ac 2 -c:v libx264 -vf yadif,scale=w=640:h=360 -preset superfast -profile:a aac_he -b:a 128k -copytb 1 -vsync 2 [other libx264 options and non-audio settings] -threads 4 -f hls /var/www/html/channel.m3u8

[output with -loglevel omitted for version information]

ffmpeg version N-78248-gf781bf3 Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 5.3.0 (Gentoo 5.3.0 p1.0, pie-0.6.5)
  configuration: --extra-cflags='-I/home/build/x264 -march=sandybridge -mtune=sandybridge' --extra-ldflags='-L/home/build/x264 -ldl -static' --enable-libx264 --enable-libfdk_aac --enable-gpl --enable-nonfree
  libavutil      55. 16.101 / 55. 16.101
  libavcodec     57. 24.101 / 57. 24.101
  libavformat    57. 23.101 / 57. 23.101
  libavdevice    57.  0.101 / 57.  0.101
  libavfilter     6. 28.100 /  6. 28.100
  libswscale      4.  0.100 /  4.  0.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc    54.  0.100 / 54.  0.100

I will try to capture the error logs when it happens, but I cannot say how long that will take.

[Carl Eugen Hoyos]

For future tickets: Please do not provide edited command lines and excerpts of your console output, always provide your actual simplified command line without using external libraries and the complete, uncut console output. Never use -loglevel warning in a bug report unless you want to report an issue with the loglevel option.

It seems to me that you uploaded an output file: Please don't do that unless specifically asked, it is nearly always useless and very often misleading.
Please record your udp source for as long as necessary and cut the resulting sample to get an input file that allows to reproduce.
Do not use ffmpeg -i input -codec copy -f mpegts to record!
Possibilities to record are: mplayer -dumpstream, tools/aviocat or (if you are sure that this is an audio issue) ffmpeg -i input -vn -acodec copy -map 0:a:0 -f rawvideo outfile. The last one has the advantage of significantly smaller files (like mplayer -dumpaudio).

[DeHackEd]

As I tried to say in my original posting, it can take days or weeks to reproduce the issue. I don't have any ffmpeg output or source material showing the issue as it happens yet. So far I've always walked in on it in a faulty state and any output is long since scrolled off the console.

I am trying to provide what I have right now in case that helps, otherwise I'll do what I can to capture and reproduce anyway but I have no idea how long (or how much disk space) this will take.

[Carl Eugen Hoyos]

Replying to DeHackEd:

I'll do what I can to capture and reproduce anyway

Please do!

but I have no idea how long (or how much disk space) this will take.

To save disk space, you could record audio-only (as explained above).

[Carl Eugen Hoyos]

Please test again with current FFmpeg, if the issue is not fixed, please provide a sample.

[DeHackEd]

Just for completion, I suspect this is a duplicate of #5319 which has an actual fix.