I think it is I who doesn't understand. :) If I ever get the time I really need to just sit down and read thru the live555 code.
For me an instance is one rtsp connection to a source. It has a statistics class that is updated and displayed thru a web console. It has some control, stop start pause, shutdown. Obviously the moment the eventloop is started it dictates another thread because otherwise it would be blocked to other requests. So for example I had all the env setup and everthing in a start function. I am now trying to at least refactor that to a static env and scheduler for all connections (is that correct?) I either need to have my class intercept the call back by having the callback more generic, or I need to make my class become a RTSPClient subclass. I am using a lot of boost::shrared pointers and the instance is contained in a map at the main application level and is passed to the stream manager for that style of stream. It is subscribed to by any number of consumers the first of which usually records to disk. I am trying the subclass idea now with just the setBaseURL moved to the protected area. From: [email protected] [mailto:[email protected]] On Behalf Of Ross Finlayson Sent: Saturday, November 26, 2011 3:23 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] problems moving to asynchronous rtsp interface Threads != instances???. Don't I still need a way of keeping all the instance data separate? How does the callback allow me to differentiate between different instances (other than just the RTSPClient* itself? Once again, I don't understand. What's an "instance". Your "RTSPClient" subclass can contain whatever fields you like. The "RTSPClient*" pointer that you get in each of your response handler callbacks will be the same "RTSPClient*" on which you made the request; it should be able to (unambigously) give you all the state that you need. And no, don't "lie" to the interface (at least, not if you expect help on this mailing list). And yes, of course the "RTSPClient*" is used internally. Once again - if you (e.g.) call fooClient->sendOptionsCommand(continueAfterOPTIONS, ourAuthenticator); Then, when the "continueAfterOPTIONS()" response handler later gets called, its first parameter will be "fooClient" - i.e., a pointer to the same "RTSPClient" object on which you made the request. Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
