GNOME Bugzilla – Bug 580716
race condition in gst_element_lost_state
Last modified: 2009-05-26 11:35:01 UTC
gst_element_lost_state has a race condition. Here's my understanding of how it can happen, but Wim understands it better. 1. Have a pipeline in PLAYING 2. Set it to PAUSED 3. Send a flushing seek After (2) the pipeline is asynchronously changing to paused. If the transition completes successfully before the seek happens, there's no race; but if we seek while the element has a GST_STATE_PENDING, the sink's call to gst_element_lost_state will fail to post an async-start message. The async-start message is needed to tell the pipeline to reset the base time when the element goes PLAYING again. Loss of this message means that the pipeline won't get a base_time reset. We haven't seen this problem very much until now because most of our pipelines run with the audio clock, which does not run in PAUSED, hence no need to distribute a new base time. But if the clock does run in PAUSED, this problem is fairly easy to hit. The solution is to post async-start (though not state-changed) in gst_element_lost_state if lost_state is called during an async state change.
Created attachment 133547 [details] [review] patch to fix the problem
That patch came from Wim, though I cannot assert anything about where he got it from.
Quote the Taymans: "Slight clarification: ASYNC_START was posted in the PLAYING->PAUSED state change but that it should be posted again with the new_base_time set to TRUE" It the posting with new_base_time=TRUE that we're missing, with this race.
Fixed in 8c26c22f2c5f976695e1f5874aaba68286b46d38