GNOME Bugzilla – Bug 627164
mad hangs when segment seek is issued
Last modified: 2013-08-20 14:02:24 UTC
Created attachment 168088 [details] code The attached code decodes a MPEG2-PS file and saves its parts to a new MPEG2-PS file. It builds a pipeline consisting from uridecodebin, audioconvert, mad ffenc_mpeg2video, twolame, mpegpsmux and filesink. It also temporarily sets the rank for the flump3dec to none, so that uridecodebin doesn't take it for decoding. Then the code sets the pipeline to paused. When state-changed message from the pipeline arrives, it issues the segment seek and sets the pipeline to playing. On segment-done message the new segment seek is issued, or, if this is a last segment played, g_main_loop_quit is called. The code also starts a timer using g_time_out_add, which queries the playing position and outputs some statistics. The problem is that the second segment-done message never arrives on windows, and that timer constantly reports the same playing position. The same code (except file paths) plays fine on Linux.
Are you sure it works fine on Linux -even 64-bit? What about this: https://bugzilla.gnome.org/show_bug.cgi?id=645895 Affects Banshee, but also Rhythmbox (but not Audacity). Could gstreamer be the underlying cause?
Is this still a problem with GStreamer 1.0? Could you get a backtrace of all threads when it hangs with a recent 1.0 GStreamer version?
mad doesn't handle seeking any longer in 1.0, and even in 0.10 mpegaudioparse has been handling that forever, so I'd say let's just close this. Please re-open if this is still an issue with 1.0 and you have an updated test case, thanks.