[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 #34 from Xavier Claessens <xclaesse at gmail.com> ---
Created attachment 332316
  --> https://bugzilla.gnome.org/attachment.cgi?id=332316&action=edit
stream: revert back to create udpsrc/udpsink on DESCRIBE for unicast

This is basically reverting changes introduced in commit f62a9a7,
because it was introducing various regressions:

- It introduces 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.
- 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.
- If a 2nd mcast client connects, the destination/port in its transport is
  ignored but its transport wasn't updated.

What this patch does:

- Revert back to create udpsrc/udpsink for unicast clients on DESCRIBE.
- Always have a tee+queue when udp is enabled. This could be optimized
  again in a later patch, but is more complicated. If no unicast clients
  connects then those elements are useless, this could be also optimized
  in a later patch.
- When mcast transport is added, it creates a new set of udpsrc/udpsink,
  seperated from those for unicast clients. Since we already support only
  one mcast address, we also create only one set of elements.

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