another RTSP server problem

Chuck Crisler ccrisler at mutualink.net
Mon Aug 5 15:45:38 PDT 2013


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?

Thank you,
Chuck


On Mon, Aug 5, 2013 at 2:23 PM, Chuck Crisler <ccrisler at mutualink.net>wrote:

> 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?
>
> Thank you,
> Chuck
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130805/da82a787/attachment.html>


More information about the gstreamer-devel mailing list