This exposes a new property, mtu, which is used to determine the
initial size of buffers from the buffer pool. If received data
exceeds this, the element gracefully handles that in a manner similar
to what we had previously: a large memory gets filled and reallocated
at the next call to "fill".
The default size is set to 1500, which should cover most use cases.
With contributions from Mathieu Duponchelle <mathieu@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=772841
Optimize GstUdpSrc for cache performance.
Move the hot properties, which are used by the read function, to the top:
@used_socket, @addr, @cancellable, @skip_first_bytes, @timeout,
@retrieve_sender_address.
Remove the unused property @ttl.
Where needed reorder so that holes are avoided (the 64-bit @timeout)
https://bugzilla.gnome.org/show_bug.cgi?id=772841
This goes around the inefficient control message based filtering and
does all the filtering kernel-side. Unfortunately this is Linux-only and
there is no IPv6 variant of it (yet).
The g_object_unref (saddr) before receiving message seems to be redundant as it
is done just before jumping to retry
Though not directly related, part of
https://bugzilla.gnome.org/show_bug.cgi?id=772841
Control messages are used only in multicast mode - to detect if the destination
address is not ours and possibly drop the packet. However in non-multicast
modes the messages are still allocated and freed even if not used. Therefore
request control messages from g_socket_receive_message() only in multicast
mode.
https://bugzilla.gnome.org/show_bug.cgi?id=772841
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
This allows disabling of sender address retrieval, which might
be useful in certain scenarios, like when the socket is connected,
or the sender address is not of interest (e.g. when receiving an
MPEG-TS stream). Disabling sender address retrieval in those
cases can have minor performance advantages.
https://bugzilla.gnome.org/show_bug.cgi?id=563323
On Windows the socket will be bound to ANY instead of the multicast group,
as binding to a multicast group does not work. Which would mean that we
override src->addr to become ANY and won't automatically join a multicast
group anymore on Windows.
On Linux we would automatically join a multicast group, keep it consistent.
https://bugzilla.gnome.org/show_bug.cgi?id=763093
On POSIX, IP_MULTICAST_LOOP is a setting for the sender socket. On Windows it
is a setting for the receiver socket. As such we will need it on udpsrc too to
allow filtering out our own multicast packets.
Otherwise we constantly create/close event file descriptors,
every time we call g_socket_condition_timed_wait() or
g_socket_send_message(s)(), i.e. a lot. Which is not
particularly good for performance.
Can't create GCancellable in ::start() here because it's used
in client_new() which may be called via the add-client action
signal which may be called before the element is up and running.
Otherwise we constantly create/close event file descriptors,
every single time we call g_socket_condition_timed_wait() or
g_socket_receive_message(), i.e. twice per packet received!
This was not particularly good for performance.
Also only create GCancellable on start-up.
From the API documentation: "Note that it is generally not
a good idea to reuse an existing cancellable for more
operations after it has been cancelled once, as this
function might tempt you to do. The recommended practice
is to drop the reference to a cancellable after cancelling
it, and let it die with the outstanding async operations.
You should create a fresh cancellable for further async
operations."
https://bugzilla.gnome.org/show_bug.cgi?id=739132
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.
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.
