[Live-devel] Transport header VLC client

[Ross Finlayson]

>  > I won't be adding such functionality to
>the distributed source code.
>
>I have implemented this functionality to build into the RTSPClient when
>RTSP_ALLOW_CLIENT_DESTINATION_SETTING is set.  In this way I can instruct
>my MPEG encoder's RTSP server where to send its multicast stream, which is
>a user requirement so that multiple encoders can exist on the same network.
>Does your comment mean that this capability, despite being disabled, could
>not be added to the distribution?

Well, if someone submits a patch that adds such functionality to the 
RTSP client code, then I *might* conceivably include it in the 
distribution, but I'm certainly not going to go out of my way to 
write it myself.

In any case, to use your example, it's bad design for the RTSP 
*clients* to be deciding which multicast address each server should 
be using, not merely because it relies upon the server having this 
ability enabled.  It makes far more sense for each *server* to choose 
(or be assigned) its multicast address, in advance (when it starts 
up), in order to avoid conflicting with the multicast address(es) 
used by other server(s) on the same network.  In general, it's the 
servers that will know this, not the clients (which might be on a 
completely separate network, and administered separately).  Also, 
what if you want to have more than one client play the same stream 
(which I imagine that you do, given that you are using multicast)? 
How does the first client know that it should choose a destination 
multicast address itself, and how do the second (and subsequent) 
clients know that they should, instead, use the multicast address 
that the first client has already given to the server?

In this case, having the clients tell the servers what multicast 
addresses to use is silly, and I see no reason to support it.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/