In the LIVE555 code, RTCP (both sending and receiving) is automated, and is not intended to be performed directly by application code. All the application code needs to do is create appropriate “RTCPInstance” objects at each end (something that's done automatically if you’re running a RTSP server or a RTSP client). You can, however, register ‘call back’ functions that get called whenever specific kinds of RTCP packet arrive; see “liveMedia/include/RTCP.hh”.
If you’re using RTSP, then you can try running “openRTSP” (with the “-Q” option) as your RTSP client; this will give you packet loss statistics (and the code (“testProgs/playCommon.cpp”) will illustrate you how to do this). In any case, note that RTP receivers (i.e., using “RTPSource”s) will use “RTPReceptionStatsDB” and “RTPReceptionStats”; RTP transmitters (i.e., using “RTPSink”s) will use “RTPTransmissionStatsDB” and “RTPTransmissionStats”. Of course, for this to work, you’ll need to have created a “RTCPInstance” object for each “RTPSink” and/or “RTPSource". (As noted above, if you’re using RTSP, then this will be done automatically; otherwise, you’ll need to create the “RTCPInstance” objects yourself.) > Furthermore, I can imagine the client knows about packet loss soon enough > (the sequence number will differ from the expected number), but I’d like the > server to know about this as soon as possible as well. How can I achieve > this? Is it possible to force sending an RR packet back to the server? Would > it be a good idea to do this that way at all? What you’re describing here is a RTCP-based retransmission mechanism (for recovery from packet loss) - i.e., the RTP/AVPF format described in RFC 4585 and RFC 4588. This is something that we don’t yet implement, unfortunately. 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
