[Live-devel] Packet loss status in RTCP RR packets

[Ross Finlayson]

> I am using live555 library to stream to proxyserver on rtp over tcp. I want to add variable bitrate mechanism for my device for that i suppose i need to verify some parameters on RTCP RR report. I was trying to look at packet loss status but everytime it was a constant value coming 0x00fffffff.

The best way to look at packet loss statistics is to use the “RTPTransmissionStatsDB” database.  That way, you don’t need to inspect RTCP packets directly (because our code already does this for you).  Unfortunately there’s currently no example code to show you how to access the “RTPTransmissionStatsDB” database, but you could look at the similar code in “openRTSP” that looks at the “RTPReceptionStatsDB” database (in “testProgs/playCommon.cpp”).


> i guess because of RTP over TCP.

Yes, and this is an illustration of why RTP-over-TCP streaming is generally a bad idea, and should be done only as a last resort.  By streaming over TCP, the TCP implementation (in each computer’s OS) will try to deliver *everything*, even if the stream exceeds the capacity of the network. However if that is the case, then, eventually, buffers in the sending OS will fill up, and writes to the TCP connection will fail.


> Is there anything that will help me to find out that network is not able to handle my current bitrate so that i can reduce it to some level and try it again at run time.

I don’t think so.  However, the mere fact that writes to the TCP socket are eventually failing (and we’re consequently closing the socket) tells you that your stream is exceeding the capacity of your network.


> One more concern is in RTPInterface::sendDataOverTCP if send fails then we are making that socket blocking and try to send it again. in that particular case if that is failing then we are removing the socket and closing the connection. What i have observed from little bit changing in code is if we retry to send the same packet in blocking mode then it is able to send again. so if we can make little retry mechanism then we can avoid closing the connection if its able to resend the data again.

No, there’s no way to do this without possibly starving the server from doing other work (and there’s no way to tell whether the write failed because the far end of the TCP connection has died, in which case ‘retrying’ might go on forever).  If you modify the supplied source code, you can expect no support on this mailing list.  Sorry.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/