GNOME Bugzilla – Bug 492729
PAUSED->PLAYING returns ASYNC when triggered from bus handler
Last modified: 2007-11-07 06:45:08 UTC
Build the attached sample and run as follow: gcc -Wall -g `pkg-config gstreamer-0.10 gstreamer-controller-0.10 --cflags --libs` seek1.c -o seek1 GST_DEBUG="*:2,default*:3" ./seek1 you hear a sweeping sine and see: 0:00:00.132081000 18641 0x804b008 INFO default seek1.c:204:main: ->PAUSED needs async wait 0:00:00.132418000 18641 0x804b008 INFO default seek1.c:228:main: ->PLAYING needs async wait 0:00:00.132763000 18641 0x804b008 INFO default seek1.c:52:event_loop: state change on the bin: NULL -> READY 0:00:00.136843000 18641 0x804b008 INFO default seek1.c:52:event_loop: state change on the bin: READY -> PAUSED 0:00:00.138055000 18641 0x804b008 INFO default seek1.c:52:event_loop: state change on the bin: PAUSED -> PLAYING now rebuild with -DPLAY_BROKEN and re run: gcc -Wall -g `pkg-config gstreamer-0.10 gstreamer-controller-0.10 --cflags --libs` -DPLAY_BROKEN seek1.c -o seek1 GST_DEBUG="*:2,default*:3" ./seek1 0:00:00.130998000 18817 0x804b008 INFO default seek1.c:187:main: ->PAUSED needs async wait 0:00:00.131356000 18817 0x804b008 INFO default seek1.c:60:event_loop: state change on the bin: NULL -> READY 0:00:00.135650000 18817 0x804b008 INFO default seek1.c:60:event_loop: state change on the bin: READY -> PAUSED 0:00:00.136100000 18817 0x804b008 INFO default seek1.c:84:event_loop: ->PLAYING needs async wait 0:00:00.136297000 18817 0x804b008 INFO default seek1.c:60:event_loop: state change on the bin: PAUSED -> PAUSED This is the probem: PLAYING needs async wait The code was working in earlier GStreamer. I suspect the change to be in the last 3 weeks.
Created attachment 98387 [details] test case
After adding some more logging I see that I also get an GST_MESSAGE_ASYNC_DONE a little later on. So what should I do with it? I've tried to set the pipeline to playing again but that does not help.
Created attachment 98412 [details] test case removed some dead code and added more debug
I see two problems: - two set_state to PLAYING, when done at the right moment make the state thread think that the second state interrupted the first state. - basesrc stops streaming because of a wrong state.
* gst/gstelement.c: (gst_element_set_state_func): Only change the state cookie if a different state was set on the element. See #492729. * libs/gst/base/gstbasesrc.c: (gst_base_src_default_query), (gst_base_src_perform_seek), (gst_base_src_default_event), (gst_base_src_set_flushing), (gst_base_src_activate_push), (gst_base_src_activate_pull): Unify flushing code, remove some old unlock code that is no longer used. Take the streaming lock when seeking to avoid races. Fixes #492729. Added some more comments.
Thanks, confirming that it works also in the actual application again. Still if there is anything done badly in the test-app, please let me know.