GNOME Bugzilla – Bug 336957
AAC typefinding overestimates probability
Last modified: 2010-02-09 10:17:05 UTC
When I play this mp3 file on an Ubuntu Dapper Flight 5 system, the playing application will crash. In addition, both Banshee and Rhythmbox will crash soon (~2-3 minutes) after startup, Rhythmbox output on importing the file into the library: [0x8143468] [rb_metadata_load] rb-metadata-gst.c:832 (20:23:33): going to PAUSED for metadata, uri: file:///[...]/Hallelujah.mp3 [0x8143468] [rb_metadata_gst_typefind_cb] rb-metadata-gst.c:563 (20:23:33): found type application/x-id3 Segmentation fault I recently upgraded to 0.10.3 of plugins-ugly, and before the upgrade did not experience this problem. File: http://www.dx13.co.uk/bug_files/Hallelujah.mp3
What versions of core, -base, -good and -ugly are you using? This file works fine for me with CVS: tim@sceptic:~/samples/audio/mp3$ gst-launch-0.10 playbin uri=file:///home/tim/samples/audio/mp3/Hallelujah-336898.mp3 -t Setting pipeline to PAUSED ... Pipeline is PREROLLING ... FOUND TAG : found by element "id3demux0". artist: Jeff Buckley album: Grace title: Hallelujah date: 1994-01-01 track count: 10 track number: 6 genre: Rock FOUND TAG : found by element "mad0". layer: 3 mode: stereo emphasis: none audio codec: MPEG-1 layer 3 bitrate: 128000 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... ...
Lib versions, including package revisions: core: 0.10.4-1ubuntu1 base: 0.10.5-0ubuntu2 good: 0.10.2-2ubuntu2 ugly: 0.10.3-0ubuntu1 ffmpeg: 0.10.1-0ubuntu1 For some reason, it looks like playbin is trying to use ffmpeg: mike@frenetri:~/Desktop$ gst-launch-0.10 playbin uri=file:///home/mike/Desktop/Hallelujah.mp3 -t Setting pipeline to PAUSED ... Pipeline is PREROLLING ... FOUND TAG : found by element "id3demux0". artist: Jeff Buckley album: Grace title: Hallelujah date: 1994-01-01 track count: 10 track number: 6 genre: Rock ERROR: from element /playbin0/decoder/ffdemux_aac1: Element doesn't implement handling of this stream. Please file a bug. Additional debug info: gstffmpegdemux.c(987): gst_ffmpegdemux_sink_activate (): /playbin0/decoder/ffdemux_aac1: failed to activate sinkpad in pull mode, push mode not implemented yet ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... FREEING pipeline ...
I tried removing the gst-ffmpeg package to see if this was somehow overriding the selection of the mad plugin. The file still wouldn't play. I double checked and I have both gst-ugly with the mad plugin installed, along with libmad. This combination works with my other mp3 files that I've tested it on, seems to be just this file. If it seems to be working in CVS HEAD, I'll wait until an update to GStreamer to see if this bug is fixed. If it's still a problem, maybe it's a problem with the way the Ubuntu packages are working and I can file a bug with them. In case it's helpful in some way, here is the output with ffmpeg removed: mike@frenetri:~/Desktop$ gst-launch-0.10 playbin uri=file:///home/mike/Desktop/Hallelujah.mp3 -t Setting pipeline to PAUSED ... ** Message: don't know how to handle audio/mpeg, framed=(boolean)false, mpegversion=(int)4 Pipeline is PREROLLING ... FOUND TAG : found by element "id3demux0". artist: Jeff Buckley album: Grace title: Hallelujah date: 1994-01-01 track count: 10 track number: 6 genre: Rock ERROR: from element /playbin0: You do not have a decoder installed to handle this file. You might need to install the necessary plugins. Additional debug info: gstplaybasebin.c(1457): prepare_output (): /playbin0 ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... FREEING pipeline ... Output of gst-inspect on the mad plugin: mike@frenetri:~/Desktop$ gst-inspect-0.10 mad Factory Details: Long name: mad mp3 decoder Class: Codec/Decoder/Audio Description: Uses mad code to decode mp3 streams Author(s): Wim Taymans <wim.taymans@chello.be> Rank: secondary (128) Plugin Details: Name: mad Description: id3 tag manipulation and mp3 decoding based on the mad library Filename: /usr/lib/gstreamer-0.10/libgstmad.so Version: 0.10.3 License: GPL Source module: gst-plugins-ugly Binary package: GStreamer Ugly Plugins (Debian) Origin URL: http://packages.qa.debian.org/gst-plugins-ugly0.10 [...]
For some reason it seems to think (wrongly I believe) that this is an AAC (mpeg-4) file (which would be handled by the 'faad' plugin and not 'mad')... not here though (using CVS), so the typefinding issue might just be fixed in CVS. Possibly a side-effect of id3demux doing typefind pull-based (=better) in CVS.
If this problem was typefinding, it should be fixed with current dapper with newer gst-plugins-base.
In reference to comment #5, I upgraded Dapper to newest GStreamer libs. Unfortunately, after upgrading to gstreamer0.10-plugins-base 0.10.6-0ubuntu1 I still get the same errors as mentioned in comments #2 and #3. Versions: core: 0.10.5-0ubuntu1 base: 0.10.6-0ubuntu1 good: 0.10.2-2ubuntu2 ugly: 0.10.3-0ubuntu1
OK, thanks for the info. This problem is definitely caused by bad typefinding when operating in push mode: gst-launch filesrc location=Hallelujah.mp3 ! queue ! id3demux ! fakesink silent=true -v yields: /pipeline0/fakesink0.sink: caps = audio/mpeg, framed=(boolean)false, mpegversion=(int)4 I don't get the same problem if I strip the ID3 tag and then try typefinding, so this seems to be a bug in id3demux. gst-launch filesrc location=Hallelujah.mp3 ! id3demux ! filesink location=tmp.mp3 gst-launch filesrc location=tmp.mp3 ! queue ! typefind ! fakesink silent=true -v yields: /pipeline0/typefindelement0.src: caps = audio/mpeg, mpegversion=(int)1, layer=(int)3
Reassigning to gst-plugins-base, since that's where the problem lies. I've just committed a fix that makes it correctly typefind the file. However, we also need to fix the AAC typefind method, which is predicting 80% probability if it manages to find just one sync point in the file, when it should definitely look for more.
I can confirm that stripping the id3 tag (as described in comment #7) both gives the same output of the typefind element ("mpegversion=(int)1, layer=(int)3") and allows me to play the file using "gst-launch-0.10 playbin uri=[filename] -t" using same setup as in comment #6.
Changing bug title to better reflect remaining problem/task.
The fix mentioned in comment #8 seems to have propagated to the latest updates to Ubuntu Dapper (my file now plays). Cheers to all involved :)
Hasn't the aac typefinding been fixed since ?
(In reply to comment #12) > Hasn't the aac typefinding been fixed since ? I guess so, it only returns some probability if it finds one sync point and after this at the correct position the second sync point.
Not reproducable with the file either.