Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#5225 closed defect (needs_more_info)

AC3 decoder fault after long running transcoding

Reported by: DeHackEd Owned by:
Priority: normal Component: avcodec
Version: git-master Keywords: ac3
Cc: jsantiago@fastmail.us Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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.

Change History (6)

comment:1 Changed 3 years ago by cehoyos

  • Keywords ac3dec removed

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).

Last edited 3 years ago by cehoyos (previous) (diff)

comment:2 follow-up: Changed 3 years ago by 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.

comment:3 in reply to: ↑ 2 Changed 3 years ago by cehoyos

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).

comment:4 Changed 2 years ago by jlsantiago0

  • Cc jsantiago@fastmail.us added

comment:5 Changed 2 years ago by cehoyos

  • Resolution set to needs_more_info
  • Status changed from new to closed

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

comment:6 Changed 2 years ago by DeHackEd

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

Note: See TracTickets for help on using tickets.