GNOME Bugzilla – Bug 707604
Short little mp3 hangs mpegaudioparse
Last modified: 2013-12-31 10:00:21 UTC
Created attachment 254222 [details] A rogue mp3 that seizes up gstreamer pipelines. The attached mp3 was created by mp3splt. In a uridecodebin commandline, it reaches this line: 0:00:00.479419988 32037 0x7ffcf40ca230 INFO task gsttask.c:300:gst_task_func:<mpegaudioparse0:sink> Task going to paused Then nothing until I hit control-C. It renders Totem unresponsive. Mplayer plays nothing and stop immediately, which is preferable.
Might be related to bug #707016. Hangs with 1.0.10, errors out properly with 1.1.4.
Note that it's not mpegaudioparse, a simple "filesrc ! typefind ! mpegaudioparse ! mad ! fakesink" pipeline for example works just fine too.
And when played with playbin, the result is Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind: Could not determine type of stream. Additional debug info: /home/mnauw/src/gst/git/gstreamer/plugins/elements/gsttypefindelement.c(1067): gst_type_find_element_loop (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... Given there is not much to typefind, one can not blame the latter, so that seems ok as well.
So seems all good with 1.2 and newer now.