stream: revert back to create udpsrc/udpsink on DESCRIBE for unicast
authorXavier Claessens <xavier.claessens@collabora.com>
Thu, 28 Jul 2016 19:33:05 +0000 (15:33 -0400)
committerSebastian Dröge <sebastian@centricular.com>
Mon, 5 Sep 2016 10:36:17 +0000 (13:36 +0300)
commit8495c47a9d1fff390aaac1f3bb5c22f760786644
tree5584dc02540da361b2d8b94ae5269205f5f0b671
parentaa0e60445d0e9e9843a5162d5a1334e0a8c7f932
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.

https://bugzilla.gnome.org/show_bug.cgi?id=766612
gst/rtsp-server/rtsp-client.c
gst/rtsp-server/rtsp-stream.c
tests/check/gst/stream.c