GNOME Bugzilla – Bug 657099
gst streamer udp multisink render function stalls when sink dissapears.
Last modified: 2014-11-25 17:52:43 UTC
Created attachment 194410 [details] [review] patch for slow udp sendto functions. Using the gstreamer rtsp server it has been found that miss-behaving streaming clients can cause the entire gstreamer rtsp server pipeline to stall as a result of the gst_mulitsink_render function stalling for ~3 seconds when clients stop receiving UDP packets in particular scenarios. Reproducible on OMAP4 hardware using WiFi (and sometimes also Ethernet) Interfaces. 100% failures occur when clients, connected via WiFi, are stopped by powering down WiFi whilst playing a stream. Occurs at low data rates. Patch attached & some switchable debug for detecting if the issue is occuring. Includes a patch submitted to address a related issue (http://gstreamer-devel.966125.n4.nabble.com/socket-error-is-ignorable-can-cause-infinite-loop-in-gstmultiudpsink-c-if-RTSP-client-connection-is-r-td2314944.html)
Please ensure that when you file a bug for GStreamer you file it selecting the right product (ie. Platform/GStreamer, not Bindings/gstreamermm*). Reassigning.
I'm not sure I agree with the analysis of what is going on with the socket. It clearly should be put in O_NONBLOCK mode, however. Random usleeps and timeouts are not a good idea, since multiudpsink could be connected to 10000 clients.
I agree the analysis is only empirical. The underlying issue could be a few things, but guessing it is the ARP lookup failing in this particular scenario. Also agree the solution's parameter's are quite specific to particular targets and posix, so it might not be a good patch to bring into releases, but could be useful for anyone finding the same problem for now. Without the retries there are is an unnecessary amount of data dropped. Unfortunately I found that pol/epol or ioctl:I_CANPUT wasn't very selective at knowing when the port was actually ready to send. Perhaps the retries could be done better by caching the unsent data and retrying next request from the gst pipeline. There is however a more general problem with the above approaches that if two clients are sharing the same udp port on the server and one causes the port to be blocked then both fail even with retries. This is of course not acceptable in general terms. One complete and more tidy resolution would be to use a separate port for each client (to avoid the cross-client impact) and only re-use ports when they are clear of would_block status. The ports will still to be non-blocking and should send data as best they can, perhaps with the above send data caching method. There will still need to be one timeout to decide when a socket is blocked and drop it, but this is more in line with what happens anyway. Unfortunately this isn't something I have time to implement as the multi-unicast use-case is not currently relevant for the RTSP application. I think this problem does however need to be solved to make gstreamer viable for general-case, robust RTSP applications.
ps read port=socket in my last comment.
Is this still a problem with 1.0 and the elements ported to use GIO for the socket operations?