GNOME Bugzilla – Bug 679639
Errors decoding AAC LATM streams
Last modified: 2018-05-06 12:10:35 UTC
Streams in question are coming as MPEG TS over DVB-T2 transmissions, mostly BBC HD and BBC One HD UK channels were used for testing. Errors appear periodically and always at the same spot in captured streams. They look like this: ERROR ffmpeg :0:: Number of bands (51) exceeds limit (41). Where numbers (bands) can be different. Or: ERROR ffmpeg :0:: channel element 0.0 is not allocated Here x.y number also can be different. GStreamer versions: gstreamer-ffmpeg-0.10.13.1-git120629.1db8779252afa264996e59c18430f70cc5582b28.plus.fc16.x86_64 gstreamer-tools-0.10.36.1-git120629.7932f62891eea5c14194ba7ee7addbfa1fd6d3ce.fc16.x86_64 gstreamer-plugins-base-0.10.36.1-git120629.8907f84ba8caf4ae27fdd7294e85102ca9524a51.fc16.x86_64 gstreamer-plugins-bad-free-0.10.23.1-git120629.65a58130baef6c8b68f777aea137023562940c09.fc16.x86_64 gstreamer-plugins-ugly-0.10.19.1-git120629.d349ba1db06d84ee1e3838dff1a7c09452f4b05f.fc16.x86_64 gstreamer-0.10.36.1-git120629.7932f62891eea5c14194ba7ee7addbfa1fd6d3ce.fc16.x86_64 gstreamer-plugins-good-0.10.31.1-git120629.8f368fc080195a5497c028ac1ef5acea83c514fd.fc16.x86_64 Repro command: gst-launch-0.10 -v playbin2 flags=0x207 uri=file:///data/data/media/bbc-hd-10.ts
Another failure mode: ERROR ffmpeg :0:: invalid band type
Players like VLC and mplayer, even ffmpeg while transcoding (same version as in gstreamer-ffmpeg), do survive these errors so I wonder could gstreamer-ffmpeg be made more robust in this respect?
To expand on error logs, decoding stops shortly after these lines like this for example: 06.57229999746724 6159 0x7fc93005a470 ERROR ffmpeg :0:: channel element 0.0 is not allocated 0:01:05.154357282 6159 0x7fc93005a470 DEBUG ffmpeg gstffmpegdec.c:2147:gst_ffmpegdec_audio_frame:<ffdec_aac_latm1> Decode audio: len=-1, have_data=192000 0:01:05.154368757 6159 0x7fc93005a470 WARN ffmpeg gstffmpegdec.c:2218:gst_ffmpegdec_audio_frame:<ffdec_aac_latm1> error: Decoding of AAC stream by FFMPEG failed. 0:01:05.154440429 6159 0x7fc93005a470 DEBUG ffmpeg gstffmpegdec.c:2224:gst_ffmpegdec_audio_frame:<ffdec_aac_latm1> return flow -5, out (nil), len -1 0:01:05.154451424 6159 0x7fc93005a470 WARN ffmpeg gstffmpegdec.c:2302:gst_ffmpegdec_frame:<ffdec_aac_latm1> ffdec_aac_latm: decoding error (len: -1, have_data: 0) 0:01:05.154460601 6159 0x7fc93005a470 LOG ffmpeg gstffmpegdec.c:2729:gst_ffmpegdec_chain:<ffdec_aac_latm1> breaking because of flow ret error ERROR: from element /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/ffdec_aac_latm:ffdec_aac_latm1: Could not decode stream. Additional debug info: gstffmpegdec.c(2218): gst_ffmpegdec_audio_frame (): /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/ffdec_aac_latm:ffdec_aac_latm1: Decoding of AAC stream by FFMPEG failed.
commit a3b0ae22d76522d0a79f5d946872c0260dd1e3b2 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Tue Jul 10 16:10:14 2012 +0200 avdec: ignore AAC errors instead of erroring out Also ignore decode errors for AAC and carry on decoding like we do for all other formats. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=679639
I have tested this patch on top of above mentioned gstreamer-ffmpeg version. With it it does survive in a way that gst-launch does not exit, but on the occurrence of the error sound disappears and doesn't come back. In the log this looks like this: :06.021960296 0:01:04.755234178 11912 0x7fcde006d700 ERROR ffmpeg :0:: Number of bands (51) exceeds limit (41). 0:01:04.755258048 11912 0x7fcde006d700 DEBUG ffmpeg gstffmpegdec.c:648:gst_ffmpegauddec_audio_frame:<ffdec_aac_latm0> Decode audio: len=-1, have_data=0 0:01:04.755268621 11912 0x7fcde006d700 DEBUG ffmpeg gstffmpegdec.c:716:gst_ffmpegauddec_audio_frame:<ffdec_aac_latm0> return flow 0, out (nil), len -1 0:01:04.755277884 11912 0x7fcde006d700 WARN ffmpeg gstffmpegdec.c:781:gst_ffmpegauddec_frame:<ffdec_aac_latm0> ffdec_aac_latm: decoding error (len: -1, have_data: 0) 0:01:04.755286634 11912 0x7fcde006d700 LOG ffmpeg gstffmpegdec.c:1176:gst_ffmpegauddec_chain:<ffdec_aac_latm0> Decoding error, trying next 0:01:04.755294418 11912 0x7fcde006d700 LOG ffmpeg gstffmpegdec.c:1192:gst_ffmpegauddec_chain:<ffdec_aac_latm0> Before (while bsize>0). bsize:0 , bdata:0x7fcde00e09a1 And there are no more log messages from ffdec_aac_latm0 from this point on. And no sound obviously.
Works for me
With 0.10 tip or 0.11 or master?
0.11 master
Created attachment 220766 [details] GST_DEBUG=ffmpeg:5 log showing the failure. gstffmpegviddec stripped due to size constraint. With 0.10 sounds still stops and does not recover for me ~1:05 into the file. Tested with yesterdays GIT, or: gstreamer-0.10.36.1-git120808.955693fc36ac38dc604e1e616e1c441cc3c25e1c -ffmpeg-0.10.13.1-git120808.1db8779252afa264996e59c18430f70cc5582b28 -base-0.10.36.1-git120808.12ef907f8a3762685da0b96391edc30a78d31805 -bad-0.10.23.1-git120808.e3b09c25b16c42ca7a83472c61054f34a31f572c -ugly-0.10.19.1-git120808.afeffcdb44135c04c5767bba8b10fab82ec9a9df -good-0.10.31.1-git120808.c1f1b62ca26106fba30fca65b0945c31da0ffe22
Forgot to mention, on top of GIT versions I have patches from https://bugzilla.gnome.org/show_bug.cgi?id=678078 applied in case that makes any difference.
I've tried a bunch of .ts files with latm from http://samples.mplayerhq.hu/A-codecs/AAC/ and none of them play for me with git master. Not clear it's an issue in libav though. I do get a couple of: libav :0:: no frame! but they seem to come from avdec_h264. Might well be an issue in aacparse too: DEBUG aacparse gstaacparse.c:463:gst_aac_parse_read_loas_audio_specific_config:<aacparse0> Need more code to parse humongous LOAS data, currently ignored WARN aacparse gstaacparse.c:560:gst_aac_parse_read_loas_config:<aacparse0> More data ignored
Shall we mark this as a duplicate of #678078 and concentrate the effort there ?
Thanks for taking the time to report this. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 678078 ***