[Live-devel] Frame drop in TCP mode

[Subbarao]

Please forgive me if it is not correct to reply to old thread. Frame 
drop issue in TCP mode mentioned below re-appeared while testing dual 
streams with primary stream at 5Mbps and secondary at 1Mbps. This time 
for comparison purpose, I have setup a third party IPCamera at same 
bitrate (Primary stream at 5Mbps + Secondary stream at 1Mbps) on the same 
network switch to which my hardware running Live555 RTSP server is 
connected.

Streamed dual streams of both my hardware running Live555 server, third 
party camera to an application running on KabyLake Pentium based system 
in TCP mode. Quite often I saw missing frames in the case of my hardware 
and not in the case of third party camera.

Increased the send buffer size to 3200KB using increaseSendBufferTo() in 
GenericMediaServer::incomingConnectionHandlerOnSocket() after following 
calls. Still seeing the frame drops.
   makeSocketNonBlocking(clientSocket);
   changeSocketOpt(clientSocket);

May be there is some socket setting or Linux settings like writing to 
/proc/sys/net/ipv4/... files to improve the streaming in TCP mode 
without drop. Any advices ?

P.S.: Unfortunately I cannot switch to UDP transmit mode in the test 
setup as the target application is using TCP mode streaming and I do not 
have freedom to change it.

Thanks,
Subbarao

On Tuesday 12 December 2017 04:06 PM, Subbarao wrote:
> 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.
>
> Thanks,
> Subbarao
>
> 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 page
>>     https://www.switch.ch/network/tools/tcp_throughput/
>> 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 possible.
>>
>>
>>> 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
>>     DEBUG_SEND
>> 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.
>> http://www.live555.com/
>>
>>
>> _______________________________________________
>> live-devel mailing list
>> live-devel at lists.live555.com
>> http://lists.live555.com/mailman/listinfo/live-devel
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel