GNOME Bugzilla – Bug 653326
RTSP server uses unicast by default
Last modified: 2011-08-16 13:17:00 UTC
Created attachment 190574 [details] [review] Allow preferring mc traffic The RTSP server defaults back to unicast when nothing else is specified. While this is not really an issue with clients like gstreamer, other clients are not that flexible to negociate the transport protocol. This patch allows to prefer multicast when creating a factory.
It would be better to copy over the gst_rtsp_media_[sg]et_protocols() API. I'm a bit surprised that a client would support rtp over multicast UDP but not unicast UDP. In any case, the client gets to choose the protocol, so if it chooses one that it doesn't support, that's not a GStreamer problem.
The choice between multicast and unicast depends on a number of network factors. Unicast is typically required when security is a bit more of a concern; while multicast puts lower requirements on the sender and the first part of the network when a lot of clients share the same source. e.g. when 20 clients connect to channel one of a 16 channel encoder; in the case of unicast you're sending out 20x4 mbps; while in the case of multicast you can do with 4 mbps and the last part of the network will do the stream multiplication on switch level.
> The choice between multicast and unicast depends on a number of network > factors. The selection of multicast and unicast; together with the gst-rtsp-server selecting different multicast adresses allows clients to steer the scalability of the network; and either fully unicast; or multicast on same multicast address as it is now is very network unfriendly.
I went for a protocols property, should give you the same functionality and more. commit 0e9ce1caf387795b4348b1c21abd1e820b3fd40a Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Tue Aug 16 15:15:19 2011 +0200 media-factory: add protocols property Add a property to configure the allowed protocols in the media created from the factory.