<div dir="ltr"><div>I have been looking in gstbin.c at the state change logic. What I have found is that find_message does find a message ASYNC_DONE from the async sink multiudpsink0. The gst_bin_set_state function declares that the element is busy and delays the state change (it was called from gst_bin_change_state_func()). However, the ASYNC_DONE message doesn't seem to ever be processed, effectively hanging the pipeline and causing the timeout. Does anyone have ideas how could this happen or can you explain the async state change logic?<br>
<br></div>Thank you,<br>Chuck<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 5, 2013 at 2:23 PM, Chuck Crisler <span dir="ltr"><<a href="mailto:ccrisler@mutualink.net" target="_blank">ccrisler@mutualink.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>My RTSP server pipeline simply accepts and relays RTP. For initial testing I have hard-coded caps that correspond to my input stream so that the pipeline should be able to work. It is a live source so it doesn't need to preroll. The problem du jour is that element multiudpsink0 is trying to asynchronously change state from PAUSED to PLAYING but that never seems to complete. As a result, the call to gst_rtsp_media_get_status() times out (g_cond_timed_wait() times out after 20 seconds) and the pipeline shuts down. I assume that this element is the one to send the media RTP to the client and element 1 is for the RTCP. Does anyone know what action or event triggers a multiudpsink to transition to the PLAYING state?<br>

<br></div>Thank you,<br></div>Chuck<br></div>
</blockquote></div><br></div>