GNOME Bugzilla – Bug 668713
Seek -> Crash. URIDecodeBin & AppSink
Last modified: 2012-02-20 04:24:59 UTC
Created attachment 206156 [details] one of many different sorts of crashes. Howdy, I've struggled with gstreamer crashes for a few days, trying to dump raw audio data after calling seek(). It always crashes, and I can't figure out why. I'm hoping that it's obvious to someone else. I'm using 0.16 from cpan, but it looks like it hasn't been altered since 0.16. This problem is independent of the GStreamer::App module that I was working on. It turns out that its API is somehow implemented with signals, so it wouldn't even be useful. I've tagged my project in a state where it crashes every time it is used a certain way: https://github.com/zpmorgan/PDL-GStreamer/tree/unknown-fail To make it crash, run the following with an audio file $FILE perl examples/spectrogram.pl $FILE
Created attachment 206229 [details] A much simpler crasher script Earlier I pointed to my own git repository, which involved PDL as a requirement. Sorry about that. Here's a script that only uses GStreamer. After having an appsink pull a buffer, the buffer is mysteriously erased, and other variables, such as $pipeline, are mysteriously changed. Seeking does not work at all, but I'm not totally convinced that this is perl-gstreamer's fault. The same seek works, however, when the pipeline is a playbin2. To run as it is, a foo.mp3 audio file is required in the same directory as crash.pl. Thanks, Zach Morgan
I haven't really looked at what crash.pl is doing, but I suspected that it would be affected by the gstreamer foreign threads problem from bug 620099 (https://bugzilla.gnome.org/show_bug.cgi?id=620099) And the patch from this bug does seem to fix crash.pl so it is possible that it is the same bug.
(In reply to comment #1) > Here's a script that only uses GStreamer. After having an appsink pull a > buffer, the buffer is mysteriously erased, and other variables, such as > $pipeline, are mysteriously changed. As Quentin said, this is indeed due to some signals (pad-added, new-buffer) being invoked from a foreign thread, for which Glib was not yet prepared. I just committed <http://git.gnome.org/browse/perl-Glib/commit/?id=6f1bc1a56e4c7c87d44caca1001cd50357f7a603> the fix mentioned in the other bug, which does indeed also seem to solve your problem. Please test extensively. *** This bug has been marked as a duplicate of bug 620099 ***
Does crash.pl work for you? there has to be a foo.mp3 in the same directory. Unfortunately it still crashes every time I run it, after playing a second of audio. The crashes are just as inconsistent as before. I'm completely clueless as to what's going on. Is there any way I can help? I'm running 5.15 with perlbrew, Glib bindings & GStreamer bindings from your git repositories. Also, the libraries (not the bindings) are from the Ubuntu 6.06 repositories. (just kidding. glib & gstreamer libraries are from ubuntu 12.04.) Thanks, Zach Morgan
Well, it kind of works, yes. It pipes one second of music¹ to pacat. Then it hangs. I think that's because you try to reuse all the elements for a second run (the second signal_connect() calls will be a problem, for example). Seeking doesn't work like you try to do it; seek() is not instantaneous. The normal procedure: • put your pipeline into "paused" (or "playing"), • watch the message bus for when the pipeline has actually transitioned into "paused" (or "playing"), then seek() and set_state("playing") <http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-eventsseek.html>. I attach a version of crash.pl that works for me. ¹ Or at least a version of it, apparently missing many frequencies, especially the low ones, and also with a slower tempo.
Created attachment 208002 [details] Seeking crash.pl
Created attachment 208021 [details] It keeps happening It still fails. I suppose this means that this problem doesn't affect everyone. Maybe it's not related to bug 620099. Your thoughts?