[Bug 770150] multiudpsink: Add round-robin property

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=770150

--- Comment #3 from GstBlub <gstblub at gmail.com> ---
(In reply to Tim-Philipp Müller from comment #2)
> There may be a performance impact though: if we send packets to the same
> client in one go, we can just re-use the address from the previous packet.
> If we round-robin to all clients, we end up going through
> g_socket_address_to_native() for every single packet.

Maybe, is it such a large impact though?  I haven't really observed any
difference and the boxes this runs on don't have much horse power (more than a
raspi, but much less than any desktop).

> I wonder if perhaps we should default to different behaviour in the
> payloader (whatever created these buffer lists) to send packets in multiple
> lists, like rtpvrawpay does. What was the format where you observed this?

What we were seeing is that when streaming FLAC audio over RTP at 24bps/96k or
higher we had significant problems with 5 or more endpoints, using the
rtpgstpay.  The endpoints towards the end of the list were still receiving
packets, but because they came in so quickly (usually like 20 packets at a
time) I believe that the udpsrc just didn't keep up reading from the socket and
pushing them through.  The socket buffer size in our case was like 200k, so
enough for maybe 130+ packets.  Placing a queue in between the udpsrc and
rtpbin also did not help as one would think, because the burst of packets came
in but too late, which then triggered rtpbin to already request a rtx, which
then just made the situation even worse.  Effectively those endpoints would
fade in and out, not playing most of the time.  And this is at data rates of
only like 1 mbps per endpoint, so really not a large volume of data.

This was the only thing that made it all work, and it works surprisingly well. 
We still placed a queue in between the udpsrc and rtpbin to make sure we can
absorb temporary bursts.

I hope this makes sense.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.