[Live-devel] Implementing SET_PARAMETER and GET_PARAMETER
matt at schuckmannacres.com
Fri Oct 31 15:38:22 PDT 2008
Ross Finlayson wrote:
>> Ross you had suggested that I perhaps start by implementing a new
>> virtual method on RTSPServer for SET_PARAMETER.
>> I looked into doing this in the code and I realized that RTSPServer
>> doesn't actually handle most of the commands for each session
>> instance, it's RTSPServer::RTSPClientSession which is a private
>> member class of RTSPServer.
>> So it looks like I'll have to at the least make RTSPClientSession
>> protected and provide a virtual constructor method to RTSPServer to
>> create a new RTSPClientSession (or derived class) from
>> I think I'll then need to virtualize all the handleCmd_* methods (or
>> at least the GET/SET_PARAMETER ones) in RTSPClientSession so that
>> derived classes can do there own thing here.
>> Does this sound something like what you were thinking Ross or were
>> you thinking of something else?
> It depends on which object's state you want to update as a result of
> the "SET_PARAMETER" operation.
> If you want to update the state of the "RTSPClientSession" object,
> then yes, you'd probably need to add a virtual function to
> If, however, you want to update the state of the "RTSPServer" object
> only, then you could probably do this by writing a generic
> implementation of "SET_PARAMETER" for "RTSPClientSession" that calls a
> new virtual function in "fOurServer" ("RTSPServer").
> And if you want to update the state of the "ServerMediaSubsession"
> object, then you would have even more work to do.
Well I want to update an object that represents the state of the session
as a whole. More specifically a camera object that is producing data for
multiple streams (at a minimum a video stream and a meta data stream).
Side effects of modifying this object could include modifying the state
of ServerMediaSubsesssion objects associated with the session (these
appear to be owned sorta kinda indirectly owned by the RTSPClientSession
object). I find it a little strange that they are created as a side
effect of the getStreamParameters() method ( at least I think we are
talking about the same thing here).
And did I mention there will be multiple of these cameras each with
there own state and sessions.
It seems like the RTSPClientSessions are the only objects in your
library that represent each instance of a session as whole, yet they are
pretty well hidden from the client API (i.e. private to the RTSPServer
The ServerMediaSession and ServerMediaSubsession objects appear to be
more factory type classes that describe how to build up the
RTSPClientSession and it's constituent SourceFramer objects and RTPSink
objects. So setting a parameter on a ServerMediaSession or a
ServerMediaSubsession object doesn't really seem appropriate.
What's nice about the RTSPClientSession is they are very general and
they don't appear to be to muddled with the specifics and I don't want
to change that.
Unless you can make any more suggestions I'll continue to post as I
move forward and let you know how things go.
More information about the live-devel