GNOME Bugzilla – Bug 602000
[playbin2] [gapless] Does state change PLAYING->PAUSED->PLAYING while it should stay in PLAYING
Last modified: 2009-11-19 11:16:08 UTC
Hi, when using latest GIT and the test7 from gst-plugins-base/gst/playback on two 4 second long Ogg/Vorbis files the following happens during the track switch: [...] 0:00:04.183242000 / 0:00:04.643990929 WARNING: Internal GStreamer error: clock problem. Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer. (gstbin.c(2308): gst_bin_do_latency_func (): /GstPlayBin2:player: Failed to configure latency of 0:00:00.000000000) 0:00:00.000000000 / 0:00:03.482993197 [...] Of course it's not 100% reproducible... :)
Full debug log can be found here, search for the above message to find the place where things go wrong: http://people.freedesktop.org/~slomo/log.bz2 The interesting part below shows, that the problem is the audio inputselector, most probably because it's not linked on any sinkpad or does not have any sinkpad at that point: 0:00:06.325151874 7202 0x1c951b0 LOG GST_REFCOUNTING gstobject.c:297:gst_object_ref:<playbin2inputselector1:src> 0x1c90340 ref 3->4 0:00:06.325161582 7202 0x1c951b0 DEBUG GST_EVENT gstpad.c:5013:gst_pad_send_event:<playbin2inputselector1:src> have event type latency 0:00:06.325171290 7202 0x1c951b0 LOG GST_REFCOUNTING gstobject.c:297:gst_object_ref:<playbin2inputselector1> 0x7f8664004650 ref 1->2 0:00:06.325180928 7202 0x1c951b0 LOG GST_REFCOUNTING gstobject.c:324:gst_object_unref:<playbin2inputselector1> 0x7f8664004650 unref 2->1 0:00:06.325190776 7202 0x1c951b0 LOG GST_REFCOUNTING gstminiobject.c:361:gst_mini_object_unref: 0x1a13a80 unref 5->4 0:00:06.325199785 7202 0x1c951b0 DEBUG GST_PADS gstpad.c:5041:gst_pad_send_event:<playbin2inputselector1:src> sent event, result 0
Created attachment 147806 [details] [review] inputselector: If there's no active sinkpad return TRUE for latency queries ...because upstream actually doesn't add any latency because there is no upstream.
Not sure if this patch is correct... maybe playbin2 should just block the selectors during group switching or something.
Of course it isn't... :) So, the problem here is worse ;) When the new group's uridecodebin gets added to playbin2, the state of uridecodebin is changed from READY->PAUSED. Unfortunately this state change is async, async-start message is posted and takes playbin2 down into PAUSED too. The idea of the gapless track changes was, that no state changes are done at all.
Solution might be, to either drop the async-start/-done messages from uridecodebin during group activation if playbin2 is already in PLAYING or to add the uridecodebins to playbin2 during the last no-more-pads.
Created attachment 148105 [details] [review] playbin2: Ignore async state changes of the uridecodebins Otherwise the async state change from READY->PAUSED of the uridecodebins will take playbin2 from PLAYING->PAUSED again during gapless group switches. Fixes bug #602000.
Created attachment 148106 [details] [review] playbin2: Ignore async state changes of the uridecodebins Otherwise the async state change from READY->PAUSED of the uridecodebins will take playbin2 from PLAYING->PAUSED again during gapless group switches. Fixes bug #602000.
commit 07dbdc79b02f03e1aa1cb8a1099a02d840ac9abf Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Thu Nov 19 10:05:28 2009 +0100 playbin2: Ignore async state changes of the uridecodebins Otherwise the async state change from READY->PAUSED of the uridecodebins will take playbin2 from PLAYING->PAUSED again during gapless group switches. Fixes bug #602000.