GNOME Bugzilla – Bug 325552
[qtdemux] segfault on m4a file
Last modified: 2006-06-14 18:30:13 UTC
Overview: --------- Running gst-launch-ext-0.8 on the file test.m4a executes the following command: gst-launch-0.8 filesrc location="test.m4a" ! qtdemux .audio_00 ! { queue ! faad ! osssink } Running this command directly causes a segfault. Running this command with "ffdemux_mov_mp4_m4a_3gp_3g2" instead of "qtdemux .audio_00" produces the correct result. The same thing happens when "test.m4a" is replaces with any other .m4a file. Steps to Reproduce: ------------------- 1) Run gst-launch-ext-0.8 on any .m4a file Actual Result: -------------- 1) The following command is run: gst-launch-0.8 filesrc location="test.m4a" ! qtdemux .audio_00 ! { queue ! faad ! osssink } 2) No audio is produced. gst-launch segfaults Expected Result: ---------------- 1) gst-launch should use some other demuxer, like "ffdemux_mov_mp4_m4a_3gp_3g2". (Not sure which one should be used.) 2) Audio should be produced. Build and Platform: ------------------- This bug refers to a stock Fedora Core 4 install, immediately upgraded to rawhide (daily updates), pulling packages from both the livna and gstreamer respositories. The most recent 0.8.11 packages are all installed, as well as all dependencies. The same bug persists when I build gstreamer and gstreamer-plugins (0.8.11) from source. Backtrace: ---------- [mcnees@localhost ~]$ gdb gst-launch-0.8 GNU gdb Red Hat Linux (6.3.0.0-1.94rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) set args filesrc location="test.m4a" ! qtdemux .audio_00 ! { queue ! faad ! osssink } (gdb) run Starting program: /usr/bin/gst-launch-0.8 filesrc location="test.m4a" ! qtdemux .audio_00 ! { queue ! faad ! osssink } Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0x809000 [Thread debugging using libthread_db enabled] [New Thread -1208624496 (LWP 13140)] RUNNING pipeline ... [New Thread 16575408 (LWP 13143)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208624496 (LWP 13140)] 0x00485e57 in qtdemux_parse_trak (qtdemux=0x92b8558, trak=Variable "trak" is not available. ) at qtdemux.c:2340 2340 for (j = first_chunk; j < last_chunk; j++) { (gdb) thread apply all bt
+ Trace 64922
Thread 1 (Thread -1208624496 (LWP 13140))
Well, a few things here. 1) gst-launch-ext was removed in 0.10; for a smarter equivalent use gst-launch playbin uri=... 2) this is not a question of launch-ext choosing the wrong demuxer; it's a bug in qtdemux for your file. Can you attach the file (or the first 500 KB of it) to this bug?
(In reply to comment #1) > Well, a few things here. > > 1) gst-launch-ext was removed in 0.10; for a smarter equivalent use gst-launch > playbin uri=... > I will install 0.10 and see if this works. I had 0.10 installed for a short while, though, and seemed to get the same error with gst-launch-ext. > 2) this is not a question of launch-ext choosing the wrong demuxer; it's a bug > in qtdemux for your file. Can you attach the file (or the first 500 KB of it) > to this bug? > I'm assuming that I can't attach that file because it is commercial. But (in case I didn't make it clear in the bug report) this is the result for every .m4a on my machine (Well, I tried about 30 files). Some of these were purchased from the iTunes music store (using sharpmusique, so they are .m4a), most were ripped from CDs and encoded .m4a using iTunes. I will completely wipe all traces of gstreamer from my machine and do a fresh install of 0.10 from source, and see if that fixes things.
Thanks for the followup. Note that 0.10 and 0.8 are parallel-installable -- you can have both without problems.
Robert McNees, may be you are trying to play protected files, see http://hymn-project.org/ Ive played 100% fine m4a files from http://billtmiller.com/mp3orgy/aac/ gst-launch-ext-0.8 01_obe_radio_one.m4a Running command-line gst-launch-0.8 filesrc location="01_obe_radio_one.m4a" ! qtdemux .audio_00 ! { queue ! faad ! osssink } gst-launch-0.10 playbin uri=file:///home/edlima/Projects/testFiles/14_obe_succubus_lp.m4a
Robert, regarding the putting of a copyrighted file into bugzilla. If you just cut out a small part of it, like the first 20% that is covered by fair use.
Robert, any updates ?
Setting as NEEDINFO. I can play all my m4a files (bought on iTMS and then decrypted) with current cvs.
I am seeing the same problem on FC5-x86-64. Gstreamer has been working fine until the last RPM update. (gstreamer-plugins-ugly-0.10.3-1.fc5) Now attempting to play a .m4a file causes the following: $gst-launch-0.10 playbin uri=file:///home/bdaniels/test.m4a Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Caught SIGSEGV accessing address 0x20
+ Trace 68745
Brian, what is the output of $ gst-launch-0.10 -v playbin uri=file:///home/bdaniels/test.m4a (with the -v switch added)? Any chance it's using the ffmpeg plugins in your case instead of qtdemux/faad?
>Any chance it's using the ffmpeg plugins in your case instead of qtdemux/faad? I don't think so. A rpm -q -a | grep -i ffmpeg finds nothing. Output: $ gst-launch-0.10 -v playbin uri=file:///home/bdaniels/test.m4a Setting pipeline to PAUSED ... /playbin0/decoder.sink: caps = NULL /playbin0/decoder/typefind.src: caps = audio/x-m4a Pipeline is PREROLLING ... /playbin0/decoder.src0: caps = NULL /playbin0/selector_audio_src0: active-pad = "sink0" /playbin0/abin.sink: caps = NULL /playbin0/decoder/queue0.sink: caps = audio/mpeg, mpegversion=(int)4, framed=(boolean)true, codec_data=(buffer)1210, rate=(int)44100, channels=(int)2 Caught SIGSEGV accessing address 0x20
+ Trace 68761
Brian: hard to say what the problem is like this, we'd really need the beginning of that file. It would be great if you could get the first 500kB of it with $ head --bytes=500k test.m4a > test-head.m4a and then attach the file to a newly-created bug report.