GNOME Bugzilla – Bug 562258
rtspsrc element takes long time to error out if the address is not valid (windows)
Last modified: 2009-06-07 14:20:33 UTC
Please describe the problem: 1. gst_rtsp_connection_connect() There's something wrong with gst_rtsp_connection_connect(). If there's no server running on target host, it returns OK (linux), timeout (windows) Should it return connection refused or something? 2. gst_rtspsrc_loop_udp() If I kill the RTSP server while streaming is going on, gst_rtspsrc_loop_udp() tries to reconnect. In linux, reconnection succeeds anyway (see 1.), and later calls to gst_rtspsrc_connection_receive() fails with connection refused error and exit the loop abnormally. In windows, reconnection fails with timeout error (takes long time), and later calls to gst_rtspsrc_connection_receive() stuck forever (fd=-1), never return. Steps to reproduce: 1. gst-launch-0.10.exe rtspsrc location=rtsp://localhost/live ! fakesink Actual results: ... 0:00:20.158000000 3956 01201F58 WARN rtspsrc gstrtspsrc.c:4328:gst_rtspsrc_open:<rtspsrc0> error: Could not connect to server. (Timeout while waiting for server response) ... Expected results: gst_rtspsrc_open() should fail immediately. Does this happen every time? yes Other information:
Created attachment 123517 [details] [review] Fixes some of #562258 1. gst-plugins-good/gst/rtsp/gstrtspsrc.c: prevents further read/write actions taken to the connect-failed socket. If I kill RTSP server while streaming is going on, rtspsrc still emits many asserts and does not clean up quickly. 2. gst-plugins-base/gst-libs/gst/rtsp/gstrtspconnection.c successful gst_poll_wait() doesn't always mean successful connect(). We should check errors by calling gst_poll_fd_has_error(). Successfully tested on linux and windows. 3. gstreamer/gstreamer/gst/gstpoll.c adds support for FD_CONNECT event (win32)
Patch by: 이문형 <iwings at gmail dot com> * gst/gstpoll.c: (gst_poll_fd_ctl_write), (gst_poll_fd_has_error): Adds support for FD_CONNECT event (win32). See #562258. Patch by: 이문형 <iwings at gmail dot com> * gst-libs/gst/rtsp/gstrtspconnection.c: (gst_rtsp_connection_connect): A successful gst_poll_wait() doesn't always mean successful connect() on Windows. We should check errors by calling gst_poll_fd_has_error(). See #561924. Patch by: 이문형 <iwings at gmail dot com> * gst/rtsp/gstrtspsrc.c: (gst_rtspsrc_loop_udp): Prevent further read/write actions taken to the connect-failed socket by erroring out quickly. See #562258.
Assigned to core/base because that's the most important change. What else needs to be done before this bug can be closed?
>> A successful gst_poll_wait() doesn't always mean successful connect() on Windows. This statement is also true on Linux. connect(s, ...) fds[0].fd = s; fds[0].events = POLLOUT; r = poll(&fds, 1, ...) if (r == 0) goto timeout; if (r < 0) goto error; /* r (> 0) is the number of structures which have nonzero revents fields * (in other words, those descriptors with events or errors reported */ if (fds[0].revents & (POLLERR | POLLHUP)) goto confailed; send (s, "Hello", ...) Without checking revents for errors, you can write to not-connected socket, which leads to ECONNREFUSED error. >> What else needs to be done before this bug can be closed? Nothing, just remove the Windows label from the comment :)
Closing as per comment #4.