[Bug 657099] gst streamer udp multisink render function stalls when sink dissapears.

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=657099
  GStreamer | gst-plugins-good | git

--- Comment #3 from p.drezet at inx-systems.com 2011-08-27 08:57:20 UTC ---
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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.