[Bug 766612] Does not take address pool configuration into account for sending unicast UDP

[GStreamer (GNOME Bugzilla)]

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

--- Comment #22 from Xavier Claessens <xclaesse at gmail.com> ---
okay.... So I think I have a better understanding of what's going on here. The
commit f62a9a7eb9fda096fb88c013d6787c28090037a2 is much more broken than I
though.

1) It introduce a leak of udpsrc elements that got wrongly fixed by adding an
hash table in commit cba045e. We should have at most 4 udpsrc for unicast:
ipv4/ipv6, rtp/rtcp. They can be reused for all unicast clients.

2) If a mcast client connects, it creates a new socket in SETUP to try to
respect the destination/port given by the client in the transport, and
overrides the socket already set on the udpsink element. That means that if we
already had a client connected, the source address on the udp packets it
receives suddenly changes, I think.

3) If a 2nd mcast client connects, the destination/port in its transport is
ignored anyway.


I think the choices we have here are:

1) Always have only one socket that we create in _join_bin(), and just make
that socket join mcast groups, always ignoring destination/port from mcast
clients in SETUP. That's basically reverting f62a9a7 and cba045e. That's the
easiest and already difficult enough.

2) Do 1) then also create an extra socket per mcast client requesting a
specific destination/port in SETUP. That means creating new udpsrc AND udpsink
(so we'll always have the tee+queue before udpsinks). Those elements will have
to be tracked into an hashtable similar to the one we already have, but for
mcast not unicast clients.

3) Do 2) then also do the complicated task of not having any udpsink elements
until SETUP just in case the first client that connects is an mcast one that
wants another destination/port. If we do this, and since in (2) we always have
a tee anyway, I would go with a fakesink rather than blocking the stream. It
turned out to be way too complicated, I still haven't succeeded in making unit
tests pass with that solution.

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