> I think it is I who doesn’t understand. J If I ever get the time I really > need to just sit down and read thru the live555 code.
Ideally, you'd need to read only the header files, and the example applications - not the library ".cpp" files. (We don't live in an ideal world, though :-) > For me an instance is one rtsp connection to a source. OK. In LIVE555, this is encapsulated by a "RTSPClient" object. But you can add more state as well (see below). > 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. Or your "RTSPClient" subclass can simply contain a member field that *points to* an object of your "instance" class. That's all I'm suggesting. Subclass "RTSPClient", and add a field called "fParentInstance" (or something) that points to an object of your existing "instance" (e.g.) class. Then, in each of your response handlers, you just cast the first parameter to be a pointer to your "RTSPClient" subclass (because you know it is), and then access "fParentInstance". Voila! You have your state back. > I am trying the subclass idea now with just the setBaseURL moved to the > protected area. I'll make this change in the next release of the software, because it's likely to be generally useful. Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
