GNOME Bugzilla – Bug 611899
hanging of gst-rtsp-server for unsupported fies:
Last modified: 2010-03-05 18:30:39 UTC
Created attachment 155309 [details] [review] patch for avoid hanging: Hi, I found that the gst-rtsp-server is hanging if the media is not a supported one(having no stream in it,or correpted stream). And the server is not accepting further requests there after. The pipeline I used is filesrc location=video.mp4 ! qtdemux ! queue ! rtpmp4vpay name=pay0 pt=96 Which is working fine for all videos having mpeg4 video codec. Suppose the video.mp4 is just a name having no media. The server is infinitely waiting there in the following line in gst-rtsp-server/gst/rtsp-media.c : ret = gst_element_get_state (media->pipeline, NULL, NULL , -1); If I change the infinite waiting option (-1) to a specific value, then the gst_element_get_state will return GST_STATE_CHANGE_ASYNC.So I think it is better specify a unique value instead of infinite option. And I here by adding this as a patch.
It should probably just listen for ASYNC_DONE and ERRORS. A (very large) timeout is probably also not so bad, just in case.
Even we used video.mp4(text file having no data) , not getting any ERROR message for long time. So I think it is making the server little unstable. Because If an application developer uses gst-rtsp-server and if one file in a playlist is an unsupported one, the server hangs there. And it is difficult for him to find out the reason. Because of not sending the response from gst-rtsp-server, further requests were not accepted by the server.
Try this patch instead: commit c7ca9b74eb18f1a27dfcd1b5f7bf1b174de89acb Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Fri Mar 5 17:51:26 2010 +0100 media: avoid doing _get_state() for state changes When preparing, use the ASYNC_DONE and ERROR messages in the bus handler to wait until the media is prerolled or in error. This avoids doing a blocking call of gst_element_get_state() that can cause lockups when there is an error. Fixes #611899
Itz working now. Thanks.