Sorry to be dense. I saw the text you provided from the FAQs, but
wasn't quite sure what it meant. As it is written, I understand this
to mean that a sink module that is part of a chain of nodes from the
source to the destination sink will receive data from an upstream
source (or a sink that is forwarding packets from an upstream node).
If the sink module is the final destination, it will consume the
packets. If it is an intermediate node, then it will transmit RTP
packets to the next downlink sink.
Is that a correct interpretation?
No. First, in our terminology, a 'sink' is only at the end of a data
chain - i.e.
source -> filter (source) -> filter (source) -> sink
Second, as explained in the FAQ, this flow of data (from one or more
sources, to a sink) is what occurs ***within an application***. It
has nothing to do with the flow of network packets ***between
applications***.
That's why RTP packets are transmitted by a 'sink' object (a
"RTPSink") - because such an object appears at the end of a flow of
data (that usually originated with data from a file source or an
encoder source). Similarly, RTP packets are received, over the
network, by a 'source' object (a "RTPSource") - because such an
object acts as a source of data (audio or video frames) that is then
consumed by other, downstream objects (such as a decoder, or a file
'sink').
Also, suppose I only have one source and one sink.
If you have a pair of applications - one transmitting data over the
network, and the other receiving data from the network - then you
won't just have "one source and one sink". Instead, each application
(transmitting and receiving) will have one sink, and one or more
sources. Once again, the 'source', 'filter', 'sink' terminology
applies only to the data flow ***within an application***.
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
