[Bug 732152] multiudpsink: use sendmmsg() to send multiple packets to multiple recipients in one go

[GStreamer (bugzilla.gnome.org)]

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

Tim-Philipp Müller <t.i.m> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|HEAD                        |1.5.1

--- Comment #3 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2014-12-16 20:28:36 UTC ---
g_socket_send_messages() landed in the latest GLib development release
(2.43.2), so will be in the 2.44.0 stable release.

commit 4dd7d79b5257730c91968bdadf90b1e6e927451a
Author: Tim-Philipp Müller <tim at centricular.com>
Date:   Fri Dec 12 23:06:07 2014 +0000

    udpsink: allocate scratch space for render functions on the heap

    and not the stack. Our allocations could get a bit too large
    to be sure it's not going to cause trouble using the stack.

commit 97a2eb7afbe004edf95a49468e48f2cab23db84d
Author: Tim-Philipp Müller <tim at centricular.com>
Date:   Tue Jun 24 01:16:37 2014 +0100

    multiudpsink: re-use send_buffers() code path for render() function

    It's like rendering a buffer list, just with one buffer.
    Has the added advantage that if there are multiple clients
    we can send the buffer to all the clients in one go.

commit 54a9a436ba04e47000300377f899a5d3858c74d8
Author: Tim-Philipp Müller <tim at centricular.com>
Date:   Tue Jun 24 01:15:25 2014 +0100

    multiudpsink: keep client list consistent during removals

    We unlock and re-lock the client lock while emitting the
    removed signal, which causes inconsistencies in the client
    list vs. the client counts. Instead, remove the client from
    the list already before emitting the signal and put it into
    a temporary list of clients to be removed. That way things
    look consistent to the streaming thread, but signal callbacks
    can still do things like get stats from removed clients.

commit fa3ef2e54ceb7437368dd6c61ef4531adc3068dd
Author: Tim-Philipp Müller <tim at centricular.com>
Date:   Tue Jun 24 00:56:27 2014 +0100

    multiudpsink: fix client count after removal

commit 7bdf7500a1b0bcfa8229cc513e45d4604a64bdb8
Author: Tim-Philipp Müller <tim at centricular.com>
Date:   Mon Jun 23 18:43:21 2014 +0100

    multiudpsink: keep client list sorted by socket family

    We make use of in the send_buffers() function if we
    need to use different sockets to send to IPv4 and
    IPv6 destinations.

commit e1a7deb27f7eeb037e3361551e5e853df0920b05
Author: Tim-Philipp Müller <tim at centricular.com>
Date:   Fri Jun 20 11:36:19 2014 +0100

    multiudpsink: add sendmmsg-ready render_list function prototype

    Add prototype for a render_list() function that can use a
    sendmmsg-style g_socket_send_messages() function once it lands
    in GLib. We can use this infrastructure to send multiple buffers
    made up by multiple memories to multiple clients in one go, which
    drastically reduces the number of syscalls made when sending
    high-bitrate video streams.

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

commit dead5c2476ff1033c8765764fbe970a084ad888a
Author: Tim-Philipp Müller <tim at centricular.com>
Date:   Thu Jun 19 19:16:01 2014 +0100

    multiudpsink: make udp client structure refcounted

    Use the refcount for memory management and keep track
    of the number of duplicate clients in a separate
    variable. This will be useful later, and means we
    don't have to hold the OBJECT_LOCK all the time.

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

commit 675384a8cb43277643ac7302c9fa5878f1893887
Author: Tim-Philipp Müller <tim at centricular.com>
Date:   Thu Jun 19 18:31:05 2014 +0100

    multiudpsink: keep count of number of unique and non-unique IPv4 and IPv6
clients

    This will come in handy later.

-- 
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.