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@5Mbps + Secondary stream@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@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel


_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Reply via email to