[Live-devel] Setting Multiple Parameters with one SET_PARAMETER command
Ross Finlayson
finlayson at live555.com
Thu Sep 27 07:06:08 PDT 2012
> In looking at our old code we were looking at fDestinationsHashTable to determine if a stream was RTP over TCP or RTP over UDP (for a server sessions status widget).
> This was done before you put the StreamState and Destinations classes in the header and the guy that did it back then added a GetClientCommProtocol() method to OnDemandServerMediaSubsession that checked the isTCP member of the Destinations object for the sessionID . I wanted to do the same but without modifying your code so I was going to put it in a child class but I can't if fDestinationsHashTable is private.
>
> If there is another better way to determine if a session is TCP or UDP
Yes - the way to do this is to inspect a "RTSPServer::RTSPClientSession" object, because that is the class that represents the state of a RTSP/RTP/RTCP stream to a client. Beginning with the latest release (version 2012.09.27) of the "LIVE555 Streaming Media" code, there's a member function
Boolean usesTCPTransport();
of the "RTSPServer::RTSPClientSession" class that you can call, to check whether a stream is TCP or UDP.
(If you need your own way to keep track of these "RTSPServer::RTSPClientSession" objects, then the way to do this is to:
- Subclass "RTSPServer" and "RTSPServer::RTSPClientSession"
- Redefine the virtual function "RTSPServer::createNewClientSession()", and reimplement it (in your "RTSPServer" subclass) to return an instance of your "RTSPServer::RTSPClientSession" subclass.
- (Perhaps) Redefine and reimplement the destructor of your "RTSPServer::RTSPClientSession" subclass also.
)
Note that, in contrast, an "OnDemandServerMediaSubsession" object is the *wrong* thing to be inspecting, because that class represents a piece of media that can be streamed, possibly several different times (sequentially or concurrently), to many different clients (which might have request TCP streaming, or UDP streaming).
And a "StreamState" object is also the wrong thing to be inspecting, because that class represents the state of a currently ongoing stream (from the piece of media represented by an "OnDemandServerMediaSubsession" object), *possibly to several different concurrent clients* (if the "reuseFirstSource" parameter was set to True).
In fact, I'm not convinced that any developer needs to have the "StreamState" class (or the "Destinations" class) visible, so there's a good chance that this visibility will be removed in future releases of the software. (So if you, or anyone, believes that they really need these classes to remain visible, then please let us know ASAP.)
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120927/2f3d649e/attachment.html>
More information about the live-devel
mailing list