This applies to all versions of faad2 in portage as of this date. (except 1.1 which will not compile). When running the faad2 front end "faad" on the command line decoding an aac file, many error messages are printed and the application causes a segmentation fault when it quits. Reproducible: Always Steps to Reproduce: 1. Log on a AMD64 gentoo machine 2. emerge faad2 3. faad your_fav_aac.aac 4. Try playing your_fav_aac.aac in xmms using the faad2 plugin Actual Results: Error: Pulse coding not allowed in short blocks Error: Pulse coding not allowed in short blocks Error: Pulse coding not allowed in short blocks Segmentation fault xmms faad2 plugin is non-functional Expected Results: Decoding test.aac took: 1.89 sec. 58.52x real-time. xmms faad2 plugin plays music
This bug is the result of faad2 using inconsistently sized data types. This (and a fix) is discussed here: http://faac.sourceforge.net/phorum/read.php?f=1&i=4981&t=4981 . Specifically, the author assumes that long is a 32-bit value. I have tested this fix and it works. The faad front end now correctly decodes aac files and the xmms plugin works. But, the segmentation fault still remains. Running in gdb, the segmentation fault occurs in a call to free() called by faadDecClose(). A post here: http://faac.sourceforge.net/phorum/read.php?f=1&i=4940&t=4940 claims to fix the segmentation fault. I have tried it and it does not. Upon examining the change, an in32 is changed to a size_t in the argument to malloc. This would only make a difference if faad was mallocing over 2GB, which is not the case. Segmentation faults in free() are usually indications of heap corruption. My guess is that there are other inconsistent data types in libfaad.
could you give me a backtrace of the segfault that occurs?
#0 0x00000038cf56a799 in mallopt () from /lib/libc.so.6 #1 0x00000038cf5693fa in free () from /lib/libc.so.6 #2 0x00000038cfe1c06b in faad_free (b=0x509290) at common.c:249 #3 0x00000038cfe0a965 in drc_end (drc=0x509290) at drc.c:54 #4 0x00000038cfe09a3e in faacDecClose (hDecoder=0x508510) at decoder.c:500 #5 0x000000000040240a in decodeAACfile (aacfile=0x7fbffff190 "01_Track01.aac", sndfile=0x7fbffff090 "01_Track01.wav", adts_fn=0x0, to_stdout=0, def_srate=0, object_type=-1073746352, outputFormat=1, fileType=1, downMatrix=80, infoOnly=0, adts_out=0, old_format=0, song_length=0x50) at main.c:632 #6 0x0000000000403693 in main (argc=-1073745520, argv=0x0) at main.c:1210
I have noticed that the faac forums have changed. Consequently, the links in the initial bug report no longer work. The change referenced was a header file used to compile libfaad which uses some different sized data types than the one software using libfaad compiles with. The header file is faad2/libfaad/structs.h Here is a diff of the modifications I made to get faad2 to work as I describe above. diff faad2/libfaad/structs.h ~/faad2_works/libfaad/structs.h 341,342c341,342 < uint32_t bytesconsumed; < uint32_t samples; --- > unsigned long bytesconsumed; > unsigned long samples; 345c345 < uint32_t samplerate; --- > unsigned long samplerate; I also examined the FAAD2-2.0 source from www.audiocoding.com dated 2004/8/14 and it includes the changes I made (presumably other changes too). Perhaps if the faad2 ebuild was used on the latest source release from audiocoding.com, everything would work.
I finally got around to trying the updated code i mentioned. Downloaded the FAAD2-2.0 source from www.audiocoding.com dated 2004/8/14, ran configure and make without modifying any code or applying any patches. The resulting faad2 frontend and xmms plugin run flawlessly. I.e. there is no segfault as I encountered with the source modifications I made to the old FAAD2-2.0 release. A new ebuild should be created that uses the most current faad2-2.0 source. And it will actually work! Unlike all the currently marked "STABLE" faad2's that don't work at all.
Have tried downloading and compiling the latest sources, but the arrangement seems a touch more complicated than compile and make....at least for this portage-spoiled luser. A revised ebuild would be greatly appreciated. :-)
I would gladly try writing an ebuild. However, in my attemt to do this, i have discovered something strange. The faad2-2.0.tar.gz that I downloaded from a sourceforge mirror link at www.audiocoding.com on 2004-9-16 (the audiocoding.com link said "Submitted: 2004-8-14) is now DIFFERENT than the one that can be downloaded now. The audiocoding.com download link now reads "Submitted: 2004/8/15". Obviously, something fishy is going on with the dates. Consequently, the one that can be downloaded now is the same as the faad2-2.0.tar.gz on the gentoo distfiles mirrors. So, was I not paying attention and downloaded the CVS snapshot? I might have, but doubt it. Things got fishier when i attempted to determine which version I actually have. A recursive diff of the two directories shows a few additional files in the "2004-8-14" version. There are also numerous changes in many of the source files (that apparently fix the bugs on amd64). However, I compared the CVS $Id: strings on all the files in the two versions. And they ALL match exactly. So, I am at a loss. I would write an ebuild, but I am the only one with the source tarball. And I cant even determine what date/version the code I do have is, so getting this exact version from CVS is impossible. My current theory is that someone messed up and posted the wrong file (possibly a modified version that had yet to be commited to CVS) as faad2-2.0.tar.gz and reverted the mistake. However, I can find no mention of this in the news or forums at www.audiocoding.com. This bug may simply have to wait until a new version of faad2 is properly released. I suggest to anyone on amd64 wishing a working mp4 player to try the latest CVS snapshot from www.audiocoding.com. The "current" version needs patches just to ./configure in gentoo, but the current versions in CVS appear to have fixed that issue. Just do "autoreconf -vif" first like the README.linux says.
Hm. A few further observations, which may prove useful to some: Gentoo's autoconf package (v. 2.59-r4) installs both autoreconf 2-13 and autoreconf 2.59, as well as a perl script to handle execution of just plain "autoreconf." On my system, the perl script seems to invoke v2.13, which doesn't do the compilation. I had to explicitly run v2.59 to get the thing to compile. Even after that hiccup, I ran into further difficulties in compiling. Something about static linkages and mp4ff. Adding -fPIC to CFLAGS (as make itself requested) got it to compile. And yay! It appears to be working. I've posted a link to this bug report in the audiocoding.com forums. I hope that if I'm not much good at actually fixing things, I can at least help to get the people who can fix them communicating.
Ok, i apoligize for any confusion my earlier post about the faad2-2.0.tar.gz file on www.audiocoding.com changing. It most likely did not change. The reason the files in it were modified is because I modified them and repackaged it under the same name (silly me). Anyways, this means that I have a working patch with the modifications to the code mentioned in Additional Comment #1, but without the seg fault. My only hypothesis is that the seg fault went away because a glibc, compiler, or some other system update.
Created attachment 40188 [details, diff] Patch to get faad2 working under amd64 An ebuild that uses this patch is coming soon...
Created attachment 40239 [details] ebuild for faad2 I ran into some problems creating this ebuild. (1) the xmms plugin whouldn't build correctly. It doesn't even build witht the faad2 ebuilds in portage! I don't know what caused this problem. I managed to fix it with a dirty hack which patches the generated makefile in faad2/plugins/xmms/src The line LIBS = "-lmp4v2 -lmp4v2" is changed to "LIBS = " (since the mp4v2 is linked in by another part of the Makefile) (2) The seg fault is back. It seems to be related to CFLAGS, and I recommend compiling with -g only. But, sometimes it seg faults and other times not. So, clearly there are still some issues here. --- This ebuild is a dirty hack, and I don't think it should be added to portage. If and when the goofy -lmp4v2 thing witht the generated makefile is fixed (it used to work fine, and this line causes no problems on my x86 system) the "hack" can be removed from this ebuild. But, the seg fault will still exist. I have tested the 15-9-2004 CVS snapshot from www.audiocoding.com. After adding a missing -fPIC, it compiles and runs without any problems. Perhaps a cvs ebuild is in order? In any case, I doubt that a stable faad2 will be possible on amd64 until the next version is released. Funny though, that it is still marked stable in portage.
faad-2.0-r3 is stable on amd64, which should have fixed this bug. i can't test it though since i don't have a aac file, so please reopen if this is still an issue
I cannot decode (play) any aac or mp4 files through XMMS with faad2 still. I've got an amd64 2800+ on an ASUS K8V motherboard. If you need more information, please let me know. I'm not a developer, but am very active in the Linux community.
oh... also, I'm using faad2-2.0-r3 on Gentoo.
I've the version 2.0-r4 installed and I still can't play AAC files with mplayer : FAAD: Failed to decode frame: Pulse coding not allowed in short blocks Boris.
Using media-libs/faad2 Latest version available: 2.0-r6 Latest version installed: 2.0-r6 $ faac file.m4a I get: Warning: Pulse coding not allowed in short blocks (repeated ad nauseum) *** glibc detected *** double free or corruption (out): 0x00000000005080b0 *** Aborted Same result for 2.0-r4 from the emerge tree.
