> Given that, why doesn't the sink take full ownership of the source object
> once you pass it to startPlaying()?
Because it doesn't :-) That design decision was made (I think; it's been well
over a decade now) because 'sources' and 'sinks' are different kinds of object.
In principle, many different objects - not just a 'sink' - may want to perform
some operation (other than 'playing') on a 'source'. And because the 'source'
and 'sink' were each created by a third party (the "testMPEG2TransportStreamer"
application code, in this case), it makes sense for the same third party to
take responsibility for reclaiming the 'source' and 'sink' objects, when it
wants to do so.
(OTOH, "FramedFilter" objects (a subclass of "FramedSource") *do* take
ownership of their upstream input source object; that's why you can delete an
entire filter chain by deleting just the tail "FramedFilter" object
("videoSource" in this case).)
Anyway, the way to avoid global variables in (your modified)
"testMPEG2TransportStreamer" application is to use the 'clientData' parameter
in the 'afterPlaying' callback. E.g., you can do something like:
struct streamParameters {
FramedSource* source;
MediaSink* sink;
// any other stream-specific parameters that you want
};
and then:
streamParameters* myStream = new streamParameters;
myStream->source = videoSource;
myStream->sink = videoSink;
videoSink<-startPlaying(*videoSource, afterPlaying, myStream); // note:
The last parameter to "startPlaying()" is different than before
and then, in "afterPlaying()":
void afterPlaying(void* clientData) {
streamParameters* myStream = (streamParameters*)clientData;
myStream->sink->stopPlaying();
Medium::close(myStream->source);
play();
}
Voila! No global variables.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
