We wanted to check our understanding of the normal source-to-sink
chain processing. The network side of our chain depends on being
called from its sink-ward filter to get started, but afterwards
continues on its own to get RTP packets from the network.
Not really. It is *always* the sink (i.e., at the end of the chain)
that initiates the data flow for each piece of data. It (in its
"continuePlaying()" virtual function) will call "getNextFrame()" on
its upstream source object. Its 'after getting' function (which was
passed in the call to "getNextFrame()") will get called after it has
received its data from upstream. This function will usually then
call "continuePlaying()" (and thus "getNextFrame()") again.
For 'filter' objects, things work similarly. Its "doGetNextFrame()"
virtual function gets called (as a result of its downstream object
calling "getNextFrame()"). This function will usually call
"getNextFrame()" on the upstream object. Its 'after getting'
function (which was passed in the call to "getNextFrame()") will get
called after it has received its data from upstream. This function
will usually call "FramedSource::afterGetting(this)" (ugly, I know)
to tell the downstream object (filter or sink) that new data is
available for it.
You should be able to check each of these things, to see where/why
the chain is stalling.
Ross Finlayson
Live Networks, Inc. (LIVE555.COM)
<http://www.live555.com/>
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
