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
