[Live-devel] Transport header VLC client

[Ashutosh Dutta]

Ross,
      I think we can still have a mechanism, where the client can make 
unicast RTSP request and provide the desired multicast transport address 
as part of SETUP request if the client knows ahead of time about the set 
of multicast addresses the RTSP server is provisioned with and the 
associated stream for each of the multicast address.

I can think of using something like SAP or some other out-of-bound 
mechanism where the client becomes aware of  that multicast address it 
needs to put in as  destination addr in its SETUP request. Thus, RTSP 
server can act like Video-on-Demand server, and with some advanced 
knowledge of the multicast address, client can make use of this 
transport header option to get a specific desired stream.

I agree that, this specific feature would be useful only for the cases 
where a group of people would like to watch the same video,(i.e, all the 
members in a family or all the members of a department)but, only one 
member of the family (head of the family) or the department (department 
head) has the control for starting the video or stopping it.

Thanks
Ashutosh


Ross Finlayson wrote:
>>  > 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.