Many Thanks Ross for the suggestion on debug. You are right. Packets were found to be dropping. I have now used  TCP_NODELAY socket option, after which the drops are not seen. I have also increased send buffer size. Yet to find out whether that has also contributed in fixing the issue.


On Sunday 10 December 2017 02:43 PM, Ross Finlayson wrote:
I feel that in a 100Mbps isolated network, 3.5Mbps is a very nominal bitrate.
What you ‘feel’ is not relevant here.  The throughput of a TCP connection 
depends upon the round-trip-time (i.e. delay) between the two endpoints, and 
(especially) the packet loss rate over the connection.  See, for example, this 
which lets you estimate the expected bitrate of a TCP connection.  Note that 
this has nothing to do with how fast your network interface happens to be.

For example, if you have a TCP connection between endpoints with a 200 ms 
round-trip time, and a 0.1% packet loss rate, then you would expect a bitrate 
of only 3.69 Mbps over the TCP connection.

Note that if your stream’s bitrate exceeds the capacity of your TCP connection, 
then eventually your sender OS’s TCP buffer will fill up, and (the server’s) 
writes to the TCP connection will start failing, causing RTP packets to be 
lost.  This is probably what is happening in your case.

This is why streaming over TCP is a bad idea, and should be avoided if at all 

I tried enabling debug messages using DEBUG macro and increasing debugLevel 
using int Socket::DebugLevel = 4. Did not see message about drop.
The error message you want to look for is at line 344 of 
“liveMedia/RTPInterface.cpp”.  You can enable this by defining the
macro when compiling this file.  This error message will get displayed when a 
write of a RTP (or RTCP) packet over the TCP connection fails (probably due to 
the stream’s bitrate exceeding the capacity of your TCP connection).

Ross Finlayson
Live Networks, Inc.

live-devel mailing list

live-devel mailing list

Reply via email to