GNOME Bugzilla – Bug 559567
`gst_base_audio_sink_sync_latency' should call `gst_base_sink_commit_state'
Last modified: 2008-11-10 14:22:11 UTC
Please describe the problem: I am writing a RTSP player now. The basesink or baseaudiosink will wait `latency' time before the actual rending work begins. I found that if I pause the pipeline when basesink or baseaudiosink is in the middle of `latency' time waiting, then set the pipeline to PLAYING, the alsasink(inherited from gstbaseaudiosink) will go into wrong state. I traced the code of gstbasesink.c, gstbaseaudiosink.c and gstbin.c and found the reason: When I set the pipeline to PLAYING, gst_bin_element_set_state will be called and this function will not set state to the sink elements which has posted ASYNC_START message while not post ASYNC_DONE message because gstbin thinks these sink elements are still `busy'. OK, When I paused the pipeline, sink elements will need re-preroll, the clock_id waiting will be unscheduled and the ASYNC_START message is posted. In gstbasesink.c, `gst_base_sink_commit_state' will be called when the clock id waiting is unscheduled and this function will post ASYNC_DONE message. So the videosink works well. But the clock id waiting of audiosink is in gstbaseaudiosink(specifically, in `gst_base_audio_sink_sync_latency' function), it will not call `gst_base_sink_commit_state' function so the ASYNC_DONE message will not been posted -- this causes the audiosink will not be set PLAYING state. I don't know how to fix this issue. I tried to add `gst_base_sink_commit_state' in gstbaseaudiosink.c but I got some runtime errors. So I am sorry I cannot provide a patch for this. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Yes Other information:
* gst-libs/gst/audio/gstbaseaudiosink.c: (gst_base_audio_sink_sync_latency), (gst_base_audio_sink_render), (gst_base_audio_sink_callback): Use gst_base_sink_do_preroll() to wait for PLAYING and before waiting for the latency to expire, fixes #559567.