GNOME Bugzilla – Bug 653840
MP3 stream starts playing with strange noise
Last modified: 2012-10-06 11:57:12 UTC
Created attachment 191118 [details] gst-feedback output The following command plays a noise of approx. 0.5s. It seems as if the meta-data header is played before the actual MP3 stream starts. gst-launch -v playbin2 uri=http://gffstream.ic.llnwd.net/stream/gffstream_w12a
I was only able to occasionally reproduce this. And by "reproduce", I actually mean segfault:
+ Trace 227657
Created attachment 193887 [details] [review] playsink: do not use dangling pointers to freed objects
I have doubts that's the same issue as reported, but the crash from this stack trace is now fixed.
When I use the following plugins directly, the noise does not occur: * souphttpsrc * mad * alsasink So the issue seems to be related to the playbin2 plugin.
Comment on attachment 193887 [details] [review] playsink: do not use dangling pointers to freed objects Hrm, I'm not sure about this: - is the G_OBJECT() run-time cast/check kosher here? Won't it throw a warning? - weak unrefs generally aren't thread-safe - chain isn't refcounted, the code seems to assume that the chain will always live longer than the ts_offset object, which may not be the case (then the callback will likely just crash afaict)
> - weak unrefs generally aren't thread-safe Sorry, that's not actually true. Weak *pointers* aren't threadsafe IIRC, but here one could take some lock (e.g. playsink's?) I guess. Another issue is that we may also need some more weak unrefs somewhere strategically.
Well, it seems the issue is a bit more intricate than what I thought. It seems similar or the same as https://bugzilla.gnome.org/show_bug.cgi?id=656715 I shall leave this for now to see if someone who knows the code pops in :)
*** Bug 657209 has been marked as a duplicate of this bug. ***
Comment on attachment 193887 [details] [review] playsink: do not use dangling pointers to freed objects That bug was fixed by ds in another way.
What's the deal with this bug? Is it fixed? Has anyone re-tested with GStreamer git? I don't see any problems with this stream with git.
(In reply to comment #10) > What's the deal with this bug? Is it fixed? Has anyone re-tested with GStreamer > git? I don't see any problems with this stream with git. ds fixed the issue he was seeing via a91237434271ed17d59bf95e0762dc9161c09864 in -base. There is some doubt that this is the issue the original report mentioned though. In any case, works for me too with latest git.
closing the bug as per comment#11. Michael, please feel free to reopen the bug in case you can reproduce the problem with latest gstreamer version.